Re: [Python-Dev] Assignment to None
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
Curt Hagenlocher wrote:
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.
It also has the virtue of being the common convention for attribute names that shadow keywords even in CPython (e.g. unittest.TestCase.assert_). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
I haven't been following this thread very closely, so I'm not sure what the status is, but I'd just like to point out that yesterday I used the fact that a[None] = b works, when I used the @memoize decorator from the wiki. This seems to provide an argument that, for symmetry's sake, we might want to keep a.None = b as well. -- Cheers, Leif
On Thu, Jun 12, 2008 at 10:13 AM, Leif Walsh <adlaiff6@gmail.com> wrote:
I haven't been following this thread very closely, so I'm not sure what the status is, but I'd just like to point out that yesterday I used the fact that a[None] = b works, when I used the @memoize decorator from the wiki. This seems to provide an argument that, for symmetry's sake, we might want to keep a.None = b as well.
That makes about as much sense as wanting to support a.42 = b since a[42] = b works. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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. In truth the current implementation of Jython allows keywords in many strange places, I expect this was done to allow for method names that are not keywords in Java so, for example, if there is a method called "print" in a Java class that we want to call (quite common) then it can be called. As far as I know appended underscores don't enter into it. Some poking around reveals that the current Jython is probably too lax here, even keywords that are common to both Python and Java can be method names (like "if"). I plan to continue to allow Python keywords that are not Java keywords to behave this way at least for
On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher <curt@hagenlocher.org> wrote: the 2.x series, though I don't think I'm going to go through the effort of allowing keywords common to both Java and Python like "if" (The 2.5 version of Jython will have a new parser so I do actually need to make these explicit choices right now). I think changing this behavior would hurt backwards compatibility too much. Maybe I'll rethink it in our 3.0 timeframe. If a convention like a trailing underscore is adopted we might move to that in the move to 3.0. -Frank
On Thu, Jun 12, 2008 at 8:06 PM, Frank Wierzbicki <fwierzbicki@gmail.com> wrote:
On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher <curt@hagenlocher.org> wrote:
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.
In truth the current implementation of Jython allows keywords in many strange places, I expect this was done to allow for method names that are not keywords in Java so, for example, if there is a method called "print" in a Java class that we want to call (quite common) then it can be called. As far as I know appended underscores don't enter into it.
After posting that message, I did what I should have done initially which was to ask Jim Hugunin about it. He said that Jython had gotten Guido's blessing to parse keywords in a context-sensitive fashion -- so that "foo.{keyword}" might be considered legal under certain circumstances. I don't, alas, have any specific cites to that end, but I suspect that we'll be following that precedent :). -- Curt Hagenlocher curt@hagenlocher.org
participants (5)
-
Curt Hagenlocher -
Frank Wierzbicki -
Guido van Rossum -
Leif Walsh -
Nick Coghlan