On Sun, Jun 8, 2008 at 10:19 PM, "Martin v. Löwis" <martin@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@hagenlocher.org