On Mon, 2008-06-16 at 22:27 +0200, M.-A. Lemburg wrote:
On 2008-06-15 16:47, Georg Brandl wrote:
Thomas Lee schrieb:
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
On 2008-06-15 16:47, Georg Brandl wrote:
Thomas Lee schrieb:
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!
We
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
On Sun, Jun 15, 2008 at 8:11 AM, Thomas Lee [EMAIL PROTECTED] wrote:
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
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
Benjamin Peterson wrote:
On Sun, Jun 15, 2008 at 8:11 AM, Thomas Lee [EMAIL PROTECTED] wrote:
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
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
Thomas Lee schrieb:
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!
We can of course decide to make assignment to
Georg Brandl wrote:
We can of course decide to make assignment to True and False
illegal in 2.7 :)
Georg
Great to know that's an option. There's little-to-no chance of this
making 2.6.
I might just avoid trying to treat True/False as real constants until
there's been a proper discussion
Sorry, that's correct. This is against 2.6 trunk.
That's the idea -- in 3.x this will be a non-issue.
It's perhaps even less of an issue than you think: In 3.0,
True and False are *already* compiled into constants. So
any additional special casing would make no difference.
Regards,
Martin
10 matches
Mail list logo
