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
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
> 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
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 discussio
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 t
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: o
Remember that it must still be possible to write (in 2.6)
True = 0
assert not True
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.
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 optimiza
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 th
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 th
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 state
11 matches
Mail list logo
