Georg Brandl wrote:
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
Ah of course. Looks like I should just avoid optimizations of
Name("True") and Name("False") all together. That's a shame!
Cheers,
T
Georg
Thomas Lee schrieb:
Option 4 just struck me: only optimize Name nodes if they have a Load
ctx. This makes even more sense: in a Store context, we almost
invariably want the name rather than the constant.
Cheers,
T
Thomas Lee wrote:
My work on the AST optimizer has led me down the path of attempting
to replace things like Name("True") with Const(Py_True) nodes. This
works fine most of the time, with the exception of the xmlrpclib
module, where True and False are actually redefined:
True, False = True, False
As I stated in an earlier email, the optimizer tries to replace the
tuple of Name nodes on the LHS with Py_True and Py_False
respectively, which has the net effect of removing xmlrpclib.{True,
False}. Obviously undesirable.
The simplest options I can think of to remedy this:
1. A setattr hack: setattr(__import__(__name__), "True", True)
2. Remove all optimization of Name("True") and Name("False")
3. Skip AST optimization entirely for the LHS of Assignment nodes
(effectively removing any optimization of the "targets" tuple)
I'm leaning towards #3 at the moment as it seems like it's going to
be the cleanest approach and makes a lot of sense -- at least on the
surface. Can anybody think of problems with this approach?
Cheers,
T
Thomas Lee wrote:
Martin v. Löwis wrote:
The question is, what is the specification for Python.
Now, that's a more interesting question than the question originally
asked (which I interpreted as "why does it work the way it works").
The only indication in the specification of that feature I could find
was:
http://docs.python.org/dev/library/constants.html
"Changed in version 2.4: Assignments to None are illegal and raise a
SyntaxError."
Now, given that this talks about the built-in namespace, this
*doesn't*
specify that foo.None=1 should also raise a syntax error.
So the implementation apparently deviates from the specification.
In Python 3, None, True, and False are keywords, so clearly, the
intended semantics is also the implemented one (and the language
description for 2.x needs to be updated/clarified).
Interestingly enough, the semantics of True, False and None are
different from one another in 2.6:
True = "blah" and False = 6 are perfectly legal in Python <=2.6.
Funny, I just ran into this. I was trying to figure out why the AST
optimization code was breaking test_xmlrpc ... turns out xmlrpclib
defines xmlrpclib.True and xmlrpclib.False and the optimizer was
trying to resolve them as constants while compiling the module. Ouch.
What happened in 3k? Were the constants in xmlrpclib renamed/removed?
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/tom%40vector-seven.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/tom%40vector-seven.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/python-python-dev%40m.gmane.org
_______________________________________________
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
