Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
Python-bugs-list
Martin v. Löwis added the comment:
I claim that this is not a bug in the existing versions. It is documented as
illegal to assign to None:
http://docs.python.org/2.7/library/constants.html?highlight=none#None
So what exactly happens if you manage to bypass the existing checks is
Roundup Robot added the comment:
New changeset 03f92a9f0875 by Benjamin Peterson in branch 'default':
create NameConstant AST class for None, True, and False literals (closes #16619)
http://hg.python.org/cpython/rev/03f92a9f0875
--
resolution: - fixed
stage: patch review -
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +daniel.urban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
New submission from Bruno Dupuis:
We found some strange behaviour of the compiler in this discussion on
python-list:
http://mail.python.org/pipermail/python-list/2012-December/636104.html
The fact is, `return` and `return None` result in inconsistent bytecode
depending on the context.
Matthew Barnett added the comment:
The same problem occurs with both `False` and `True`.
--
nosy: +mrabarnett
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
Bruno Dupuis added the comment:
To me, the whole issue is at line ~ 480 in peehole.c in the
LOAD_NAME/LOAD_GLOBAL switch case.
This explains the difference between `return` and `return None` as the former
is actually compiled to LOAD_CONST. OTOH, `return None` has to pass the optim
pass to
Bruno Dupuis added the comment:
line 426 in peehole.c :
if (codestr[codelen-1] != RETURN_VALUE)
goto exitUnchanged;
before the optim. I'm quite sure it's here. i patch and see...
--
___
Python tracker rep...@bugs.python.org
Changes by Alex Gaynor alex.gay...@gmail.com:
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
Python-bugs-list mailing
Changes by Chris Kaynor ckay...@zindagigames.com:
--
nosy: +DragonFireCK
versions: +Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
Python-bugs-list
Bruno Dupuis added the comment:
This first patch spots the issue, but doesn't solve it if the bytecode of the
function is 32700 (see PyCode_Optimize comment). However with this patch, we
get the LOAD_CONST anytime for None, True and False.
There is two questions :
1- is it safe to strip all
Terry J. Reedy added the comment:
(2.6 is security fix only)
Stripping truly dead code after return is really tricky in general because
a) it might be in a conditional block, and
b) unreachable yield and assignment can affect compilation.
Assignments that make names local are detected on a
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
Python-bugs-list
Bruno Dupuis added the comment:
We definitely need to put the code that loads constants with LOAD_CONST out of
the optimization code. It's not optim, it's a language feature: None *is* a
'singleton' constant.
I'm trying to figure out how to change compile.c to achieve this, as it's my
first
Benjamin Peterson added the comment:
Here's what I think we should do for 3.4. Nick, care to commment?
--
Added file: http://bugs.python.org/file28219/const-node.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
Nick Coghlan added the comment:
First reaction is +1 for finally switching to real constant nodes in the AST
for 3.4+. This is an inherited behaviour from 2.x where these were ordinary
names rather than true keywords, so we weren't able to completely disallow
overwriting them.
As a smaller
Alex Gaynor added the comment:
Nick, None was a constant even in 2k
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
Nick Coghlan added the comment:
True and False weren't, though (and even None wasn't a proper keyword)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
Nick Coghlan added the comment:
The difference in the errors below is the reason the systematic fix in
Benjamin's patch simply wasn't practical in 2.x (as it would have required a
complex deprecation dance to turn None, True and False into real keywords):
Python 2.7.3 (default, Jul 24 2012,
20 matches
Mail list logo
