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.
Although this appears to raise the spectre of code written for Jython or
IronPython not being compatible with CPython, in reality if they are
using Java or .NET objects then they are already incompatible with
CPython (IronPython doesn't work by proxying .NET objects by the way -
you work directly with them but the DLR 'catches' attribute look ups etc
to add Python methods to basic types and do 'other magic' like wrapping
Python functions as delegates).
This at least enshrines the current IronPython behaviour with the veneer
of respectability.
Michael Foord
Alex
On Mon, Jun 9, 2008 at 1:28 AM, Michael Foord <[EMAIL PROTECTED]> wrote:
Steven D'Aprano wrote:
On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote:
So, it's okay to setattr the attribute name "None" but not okay to set it
directly?
I suspect this is off-topic for python-dev, and would be better on
comp.lang.python or similar, but for what it's worth, I consider having an
attribute named 'None' bad practise, regardless of any runtime checks. But
as part of Python's "we're all consenting adults here" philosophy, I
wouldn't approve of expensive or extensive run-time checks specifically to
prevent it. If you really have to name your attribute None, and are prepared
to live with the consequences, then go ahead.
FWIW Curt is asking because he is on the team responsible for implementing
IronPython.
In .NET you have several enumerations with members called None, for example
'Alignment.None'. It would be inconvenient for IronPython users if it
enforced this particular syntax rule of Python's; that not only is
assignment to None disallowed but that members named None are invalid
syntax.
The question is, what is the specification for Python. Is it that assignment
to None is disallowed and the naming of members called None being invalid
syntax is merely an artefact of the implementation of this, or does Python
require this...
Michael Foord
In a similar fashion:
class Parrot(object):
... pass
...
p = Parrot()
p.1 = 'spam'
File "<stdin>", line 1
p.1
^
SyntaxError: invalid syntax
setattr(p, '1', 'spam')
_______________________________________________
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/aleaxit%40gmail.com
_______________________________________________
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
