[Python-Dev] Assignment to None

[Curt Hagenlocher]

On Sun, Jun 8, 2008 at 10:19 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>
> > So, it's okay to setattr the attribute name "None" but not okay to set
> > it directly?  Is this deliberate or is it an unintentional side effect
> > of parser changes to prevent assignment to None?
>
> It's deliberate. setattr(o, "foo bar", "baz") also works, even though
> "foo bar" is not an identifier. setattr doesn't take the Python grammar
> into account, but only the object's structure.

Thanks for this example; I found it useful.


As Michael says, my primary interest in asking this question is
because I'm working on IronPython.  Compatibility with CPython is
extremely important for us, so I need to understand exactly what
behavior is mandated. Here's a recap of the ground this thread has
covered:

1. In all versions, direct access to members whose names are reserved
keywords (such as "print") is not allowed.
2. In Python 2.5 and 2.6, "True", "False" and "None" are not keywords,
but direct assignment to a member named "None" is specifically
prevented by the parser.  Members named "None" may, however, be read
directly if they are present.  There is no special handling for "True"
or "False".
3. In Python 3.0, "True", "False" and "None" are keywords.

This eventually leads to a problem for us in interoperability with
other CLR code. One example, as Michael points out, is that "None" is
a relatively common member of enumeration types. Now for IronPython
2.0, we're targeting compatibility with CPython 2.5.  If we duplicate
2.5's behavior and allow direct reads but not direct writes for a
member named None, we'd be okay for the enumeration example.
Enumerated values aren't writable anyway.

However, this sets us up for a problem with some hypothetical future
version of IronPython that targets 3.0 compabililty.  At that point,
we'll face the unpleasant task of having to choose between compability
and interoperability.  We haven't really had to do this before now
because the convention in CLR-based code is typically that
publicly-exposed symbols start with a capital letter -- and all of the
existing reserved words in Python are lower-case.  It's likely to be a
much bigger issue with Jython, given the Java convention of having
lower-cased method names.

If I recall correctly, Jython handles this by appending a trailing
underscore to the imported name and there's no reason why we couldn't
do something similar.

--
Curt Hagenlocher
curt at hagenlocher.org