Nick Coghlan added the comment:
I'm unlikely to ever get to this (especially as 3.5 is now in security-fix only
mode), so closing it again.
--
nosy: +freakboy, freakboy3742
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
Nick Coghlan added the comment:
Temporarily reopening this as a docs bug - I think it's worth mentioning in the
"Porting to Python 3.5" section of the What's New docs and as a "version
changed" note in the dis module docs, as even though it's obscure, anyone that
was inadvertently relying on
Steve Dougherty added the comment:
Anyone care to review issue11205-v3.patch ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Terry J. Reedy added the comment:
I downloaded and tried to apply to 3.5 (then default) as it was last Saturday,
before the .b1 cutoff. Only ceval.py and test_compile.py patches worked.
Everything else failed. You need to update your repository (3.5 is now a
branch and default is 3.6) and
Roundup Robot added the comment:
New changeset 6f05f83c7010 by Benjamin Peterson in branch '3.5':
in dict displays, evaluate the key before the value (closes #11205)
https://hg.python.org/cpython/rev/6f05f83c7010
New changeset ba9e4df5368c by Benjamin Peterson in branch 'default':
merge 3.5
Steve Dougherty added the comment:
I've added a change to the bytecode magic number as well. I don't see a magic
tag anymore, either in the code or for recent versions.
There are autogenerated changes to Python/importlibs.h. Is my understanding
correct that these are not to be committed?
Eric Snow added the comment:
Changes to importlib.h should always be committed. It is the frozen
importlib._bootstrap module, which is the implementation of the import system
used by the interpreter. So failure to commit changes to importlib.h means
your changes to importlib._bootstrap will
Steve Dougherty added the comment:
I've added the importlib.h changes and changed the name of the test to be more
descriptive.
--
Added file: http://bugs.python.org/file39228/issue11205-v3.patch
___
Python tracker rep...@bugs.python.org
Steve Dougherty added the comment:
I've added a patch to change the order of evaluation and of STORE_MAP's
arguments. It includes a test incorporating the review on the previous version.
I noticed I had to remove existing .pyc files to avoid TypeErrors about values
being unhashable. I take it
Nick Coghlan added the comment:
The pyc issue suggests the magic number embedded in pyc files to indicate
bytecode compatibility needs to be incremented. If I recall correctly, that
lives in Lib/importlib/_bootstrap.py these days.
--
___
Python
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
priority: low - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Steve Dougherty added the comment:
Any word on either changing the documentation to match the behaviour or fixing
this as a bug?
--
nosy: +sdougherty
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
Guido van Rossum added the comment:
This needs a code patch. But it can only be fixed for 3.5.
On Apr 7, 2015 11:21 AM, Steve Dougherty rep...@bugs.python.org wrote:
Steve Dougherty added the comment:
Any word on either changing the documentation to match the behaviour or
fixing this as a
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
Ned Batchelder added the comment:
Since this is documented in the Python Language Reference, it doesn't make much
sense to have it describe one way for 3.3 and another for 3.4, does it? By
definition, doesn't that make this an implementation dependency? We should
update the docs to say that
Terry J. Reedy added the comment:
I strongly agree with Guido that we should fix the code. To me, defined
left-to-right evaluation of sub-expressions within an expression is a feature.
C's 'implementation defined' is a nuisance.
I do not think we should temporarily change the doc. In other
Guido van Rossum added the comment:
I am sticking with my opinion from before: the code should be fixed. It
doesn't look like assignment to me.
I am fine with making this a feature only fixed in 3.4. (You can even fix
the docs in 3.3 as long as you fix them back for 3.4.)
Minor note for
Ezio Melotti added the comment:
I came across the same problem in #16777.
IMHO the current behavior is better, and the documentation should be fixed
instead, for the following reasons:
1) it's consistent with assignments, where the RHS is evaluated before the LHS
(see also msg128500). This
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
priority: high - low
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
Terry J. Reedy added the comment:
Today in pydev thread chained assignment weirdity Guido said
http://permalink.gmane.org/gmane.comp.python.devel/135746
I agree that we should be *very* conservative in changing the
meaning of existing opcodes (adding new one is a different story).
...
Hm. I
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
Changes by Terry J. Reedy tjre...@udel.edu:
--
components: +Interpreter Core -None
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Changes by Sandro Tosi sandro.t...@gmail.com:
--
nosy: +sandro.tosi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
Terry J. Reedy tjre...@udel.edu added the comment:
If I understand, since the present patch uses present opcode semantics, adding
a rotate, it could go into 2.7 and 3.2. Correct?
3.3 could get an improved patch that instead changed opcodes to expect key and
value in the other order.
Changes by Skip Montanaro s...@pobox.com:
--
nosy: -skip.montanaro
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
New submission from takayuki takayuki...@star.odn.ne.jp:
Running the following code shows 2 1 4 3, but in reference manual
http://docs.python.org/reference/expressions.html#expression-lists
the evaluation order described as
{expr1: expr2, expr3: expr4}
def f(i):
print i
return i
Changes by yeswanth swamiyeswa...@yahoo.com:
--
nosy: +swamiyeswanth
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
Skip Montanaro s...@pobox.com added the comment:
Here's a patch.
--
keywords: +patch
nosy: +skip.montanaro
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20753/compile.diff
___
Python tracker
Skip Montanaro s...@pobox.com added the comment:
Working on a test case too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Changes by Skip Montanaro s...@pobox.com:
Removed file: http://bugs.python.org/file20753/compile.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
Skip Montanaro s...@pobox.com added the comment:
It's not so easy as first appeared.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
Skip Montanaro s...@pobox.com added the comment:
Okay, this looks better. I was confusing myself with leftover .pyc
files I think. Test included.
--
Added file: http://bugs.python.org/file20754/compile.diff
___
Python tracker rep...@bugs.python.org
Skip Montanaro s...@pobox.com added the comment:
Georg, I think this might need to sneak into 3.2.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
Georg Brandl ge...@python.org added the comment:
I don't think so -- it's a very minor deviation from the spec and not a
critical bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
Skip Montanaro s...@pobox.com added the comment:
3.2 and earlier versions are all frozen, but for 3.3 it might make sense to
bump the version number of the bytecode and change STORE_MAP to take the key
and value in the opposite order, thus allowing to remove the ROT_TWO I had to
add to make
R. David Murray rdmur...@bitdance.com added the comment:
Interesting. I would actually have expected the observed behavior. I think of
the : in a dictionary literal as an assignment.
--
nosy: +r.david.murray
___
Python tracker
Georg Brandl ge...@python.org added the comment:
BTW, it would be nice to know if this behavior was consistent with the docs at
any time (the merge of the AST branch in 2.5 might be an obvious candidate
where it was broken).
Also interesting would be what other implementations of Python do.
Skip Montanaro s...@pobox.com added the comment:
As Georg suggested, it is correct in 2.4, wrong in 2.5.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
___
___
Python-bugs-list
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
sigh If only a test had been checked-in eight years ago ...
It looks like a number of things have to be changed in order to bring behavior
back to what the docs promise. Dict literals and dict comprehensions need to
be
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
takayuki, a special thanks to you for submitting such a well-researched bug
report :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11205
Skip Montanaro s...@pobox.com added the comment:
To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD
opcodes need minor modifications (just switch the u and w variable
assignments).
Either of which would not be possible in anything other that 3.3 or
later, right?
--
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
How much to change and how far to backport may make for a good python-dev
discussion.
ISTM that changing generated code goes hand-in-hand with changing opcode
semantics (as long as the magic number gets bumped). OTOH,
45 matches
Mail list logo