> > But, overall the necessary changes to the implementation and to the
> > semantics (e.g. of the 'for' statement) seem prohibitive to me.
^^^ (I meant 'from' of course)
> Really? Even for Py3K?
The implementation wouldn't be a problem for Py3K; I was under the
impression that you thought this could be put in earlier.
But the change in semantics is very hard to swallow to me. It
definitely seems to be come murkier.
> > I also think that the namespace implementation will be quite a bit
> > less efficient than a regular dictionary:
>
> Spacewise yes. They'd me much faster in use. This is a space/speed
> tradeoff.
Agreed; though the speedup comes from circumventing the dictionary
altogether.
> Why not replace the key and value pointers with the association pointer.
> Then you'd get back a little of the space.
Yes; assuming that a speedy getitem is not an issue, the hash table
could become an array of pointers to associations.
> Will they really be harder to explain? Why not explain them
> a different way?
>
> "The statement:
>
> from spam import foo
>
> copies a name binding for foo from module spam to the current
> module."
>
> Eh, I guess I can see why someone would find this
> harder....
Yes -- the concept of a name binding as an object in itself is hard;
and it's hard to understand why it is needed.
> Good point. Perhaps assinging in the client module
> should break the connection to the other module. This would
> require some extra magic.
More murkiness.
> > All in all, I think these semantics are messy and unacceptable. True,
> > object sharing is hard to explain too (see diagram on Larning Python
> > page 60), but you'll still have to explain that anyway because it
> > still exists within a namespace; but now in addition we'd have to
> > explain that there is an exception to object sharing... Messy, messy.
>
> Well, I don't have a problem with object sharing, so the notion
> of sharing namespaces doesn't bother me. I undertand that
> some folks have a problem with object sharing and I agree
> that they'd have problems with name sharing. OTOH, I don't
> think you'd consider the fact that some people have difficulty
> with object sharing to be sufficient justification for removing
> the feature from the language.
Object sharing is something you have to learn very early on; something
like "objects drop under gravity". Name binding sharing is something
that can effectively be skirted initially, but at some later point it
bites you (sort of like mutable default arguments do); this is more
comparable to discovering Einstein's relativity.
> > I claim that it's not foolproof at all -- on the contrary, it creates
> > something that hides in the dark and will bite us in the behind by
> > surprise,
>
> How so?
Because the tendency of tutorials will be to avoid mentioning
namespaces at all until you get to the appendix at the end titled
"Implementation Details."
> I'm not sore. But it was a bigger (IMO) backward incompatibility.
Sometimes a bigger incompatibility that is easy to explain is more
acceptable than a very subtle one that breaks code in very subtle
ways. Anyway, let's drop this comparison; you can't objectively
measure how backwards incompatible something us.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4