Tony Nelson wrote:
At 4:46 PM +0100 6/9/08, Michael Foord wrote:
Alex Martelli wrote:
The problem is more general: what if a member (of some external
object we're proxying one way or another) is named print (in Python <
3), or class, or...? To allow foo.print or bar.class would require
pretty big changes to Python's parser -- I have vague memories that
the issue was discussed ages ago (possibly in conjunction with some
early release of Jython) but never went anywhere much (including
proposals to automatically append an underscore to such IDs in the
proxying layer, etc etc). Maybe None in particular is enough of a
special case (if it just happens to be hugely often used in dotNET
libraries)?
'None' as a member does occur particularly frequently in the .NET world.
A halfway house might be to state (something like):
Python as a language disallows you from having names the same as
keywords or 'None'. An implementation restriction specific to CPython is
that the same restriction also applies to member names. Alternative
implementations are free to not implement this restriction, with the
caveat that code using reserved member names directly will be invalid
syntax for CPython.
...
Or perhaps CPython should just stop trying to detect this at compile time.
Note that while assignment to ".None" is not allowed, setattr(foo, "None",
1) then referencing ".None" is allowed.
I'm +0 on this at the moment, but I can understand the desire for it.
Maybe we should stop trying to check for this assignment on attributes?
Currently there are separate checks for assignment to None: one for the
"foo.None = ..." form, another for the "None = ..." form. Removing the
check for the former looks like it would be a one-liner.
Cheers,
T
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
