[Python-Dev] xmlrpclib.{True, False} (was Re: Assignment to None)

[Thomas Lee]

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 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 
>>>
>>
>> _______________________________________________
>> 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/python-python-dev%40m.gmane.org 
>>
>>
>
>