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 at 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 at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/tom%40vector-seven.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4