[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: See also issue33492. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: I was pointing out what to me is a second related contradiction in the doc, between one sentence and the next. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: I'm currently not very interested in philosophizing about why we allow one syntax but not the other. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: (The nosy list change was an accident of my local copy not being complete refreshed before posting.) If (b=b, *c) were evaluated in order, then the byte code for b=b and any subsequent keyword arguments would have to be put aside, such as in a separate

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Looks like Terry accidentally removed Serhiy. Adding him back. -- nosy: +Guido.van.Rossum, serhiy.storchaka ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: It should be possible to make the compiler emit code that evaluates the arg values left to right in all cases. -- ___ Python tracker ___

[issue23316] Incorrect evaluation order of function arguments with *args

Change by Terry J. Reedy : -- nosy: -serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23316] Incorrect evaluation order of function arguments with *args

Change by Serhiy Storchaka : -- versions: +Python 3.11 -Python 3.4, Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue23316] Incorrect evaluation order of function arguments with *args

Serhiy Storchaka added the comment: Would not be be better in long term to get rid of irregularities? It would make the grammar simpler and the documentation clearer. The only use case of such syntax in wrappers, but they always can be rewritten in other style, with natural order of

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: FYI: https://github.com/PyCQA/pylint/issues/4586 -- ___ Python tracker ___ ___ Python-bugs-list

[issue23316] Incorrect evaluation order of function arguments with *args

Guido van Rossum added the comment: Well, it seems we're stuck -- we can't make the grammar more restrictive (at least, I don't think we should, since it is a backwards incompatibility), so we'll have to live with the exception. Since it is now clear what the rule is, we can update the

[issue23316] Incorrect evaluation order of function arguments with *args

Serhiy Storchaka added the comment: See also thread "Order of positional and keyword arguments" on the Python-Dev mailing list (https://mail.python.org/archives/list/python-...@python.org/thread/I6AUYV6DVEMP7XVYVDWC62N6PK6FHX3H/). -- nosy: +serhiy.storchaka

[issue23316] Incorrect evaluation order of function arguments with *args

n compiles as if written that way. How often does it rewrite code to make it correct? I think it would have been better to have stuck with 'positional before keyword'. Can we consider deprecating something rare and easy to get wrong? Thinking more, I might prefer leaving the Evaluation Order sec

[issue23316] Incorrect evaluation order of function arguments with *args

positional args, keyword args, *args, and **kwargs? (Fortunately the evaluation order is independent from the function definition, so it's really just all permutations of those four things.) -- ___ Python tracker <https://bugs.py

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: The particular example of left-to-right function evaluation in https://docs.python.org/3/reference/expressions.html#evaluation-order is "expr1(expr2, expr3, *expr4, **expr5)". Joshua's claim, without evidence, that "'f(*a(), b=b())' will evalu

[issue23316] Incorrect evaluation order of function arguments with *args

Irit Katriel added the comment: I don't think this is true anymore: >>> def a(): ... print('a') ... return (1,2) ... >>> def b(): ... print('b') ... return (3,4) ... >>> def f(*args, b=None): ... print('f') ... >>> f(*a(), b=b()) a b f >>> -- nosy: +iritkatriel

[issue29652] Fix evaluation order of keys/values in dict comprehensions

Change by Brett Cannon : -- resolution: -> fixed stage: -> resolved status: -> closed ___ Python tracker ___ ___

[issue33492] Updating the Evaluation order section to cover *expression in calls

Change by Terry J. Reedy : -- versions: -Python 3.5 ___ Python tracker ___ ___

[issue33492] Updating the Evaluation order section to cover *expression in calls

Change by Eric Lebigot : -- nosy: +Eric Lebigot ___ Python tracker ___ ___

[issue33492] Updating the Evaluation order section to cover *expression in calls

New submission from Martijn Pieters <m...@python.org>: Can the *Evaluation order* (_evalorder) section in reference/expressions.rst please be updated to cover this exception in a *call* primary (quoting from the _calls section): A consequence of this is that although the ``*expr

[issue29652] Fix evaluation order of keys/values in dict comprehensions

janzert added the comment: Just as a note so the email discussion isn't forever lost to the void. In an unrelated thread on python-dev recently there was a short discussion on this topic in which both Guido van Rossum[1] and Tim Peters[2] gave the opinion that this

[issue29652] Fix evaluation order of keys/values in dict comprehensions

Nick Coghlan <ncogh...@gmail.com> added the comment: The current discrepancy is odd when you compare it to the equivalent generator expression: {k:v for k, v in iterable} dict(((k, v) for k, v in iterable)) It would never have occurred to me to expect the evaluation order to

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue29652] Fix evaluation order of keys/values in dict comprehensions

Raymond Hettinger added the comment: I think the current behavior is correct and desirable (as you say, it follows the order that would take place in an assignment, making it easy to roll-up existing for-loop code into a dict comprehension or to unroll and existing comprehension). Also, I

[issue29652] Fix evaluation order of keys/values in dict comprehensions

Changes by Evangelos Kounis : -- nosy: +EvKounis ___ Python tracker ___ ___

[issue29652] Fix evaluation order of keys/values in dict comprehensions

Changes by Xiang Zhang : -- nosy: +xiang.zhang ___ Python tracker ___ ___ Python-bugs-list

[issue29652] Fix evaluation order of keys/values in dict comprehensions

New submission from Jim Fasarakis-Hilliard: Reported from [1] and similar to issue11205 Currently the evaluation order for keys and values in a dictionary comprehension follows that of assignments. The values get evaluated first and then the keys: def printer(v): print(v, end

[issue26020] set_display evaluation order doesn't match documented behaviour

Changes by Raymond Hettinger : -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue26020] set_display evaluation order doesn't match documented behaviour

Roundup Robot added the comment: New changeset aa2bf603a9bd by Raymond Hettinger in branch '2.7': Issue #26020: Add news entry https://hg.python.org/cpython/rev/aa2bf603a9bd -- ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Roundup Robot added the comment: New changeset a8d504600c18 by Raymond Hettinger in branch '2.7': Issue #26020: Fix evaluation order for set literals https://hg.python.org/cpython/rev/a8d504600c18 -- ___ Python tracker <rep...@bugs.python.org>

[issue26020] set_display evaluation order doesn't match documented behaviour

Roundup Robot added the comment: New changeset 0967531fc762 by Raymond Hettinger in branch '3.5': Issue #26020: Fix evaluation order for set literals https://hg.python.org/cpython/rev/0967531fc762 -- nosy: +python-dev ___ Python tracker <

[issue26020] set_display evaluation order doesn't match documented behaviour

Raymond Hettinger added the comment: I've got it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue26020] set_display evaluation order doesn't match documented behaviour

R. David Murray added the comment: Ping. (Raymond, if you are OK with someone else committing this, you could un-assign it.) -- nosy: +r.david.murray ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Serhiy Storchaka added the comment: > Please don't forget to fix BUILD_SET_UNPACK to match. Isn't it already correct? > Also, please add the following test: "{*{True, 1}}" Did you meant "{*{True}, *{1}}"? -- ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Neil Girdhar added the comment: Ah, sorry, I somehow went cross-eyed. Not sure offhand which test would test the BUILD_TUPLE_UNPACK, but I think you're right Serhiy. Could just add both? -- ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Neil Girdhar added the comment: Please don't forget to fix BUILD_SET_UNPACK to match. -- ___ Python tracker ___

[issue26020] set_display evaluation order doesn't match documented behaviour

Neil Girdhar added the comment: Also, please add the following test: "{*{True, 1}}" Should be True. -- ___ Python tracker ___

[issue26020] set_display evaluation order doesn't match documented behaviour

Serhiy Storchaka added the comment: LGTM. -- components: +Interpreter Core -Documentation nosy: +serhiy.storchaka stage: patch review -> commit review type: -> behavior ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Changes by Raymond Hettinger : -- priority: normal -> high ___ Python tracker ___

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue26020] set_display evaluation order doesn't match documented behaviour

Hamish Campbell added the comment: > Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that > `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, > minus their str() output, and my example is very unlikely to ever appear in > actual code. No I

[issue26020] set_display evaluation order doesn't match documented behaviour

Changes by Raymond Hettinger : Added file: http://bugs.python.org/file41518/build_set2.diff ___ Python tracker ___

[issue26020] set_display evaluation order doesn't match documented behaviour

Changes by Raymond Hettinger : -- versions: +Python 2.7, Python 3.5 ___ Python tracker ___

[issue26020] set_display evaluation order doesn't match documented behaviour

Changes by Raymond Hettinger : -- stage: -> patch review ___ Python tracker ___

[issue26020] set_display evaluation order doesn't match documented behaviour

Raymond Hettinger added the comment: The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily loops backwards (it looks like it was copied from the BUILD_TUPLE opcode). -- assignee: docs@python -> rhettinger nosy: +rhettinger ___

[issue26020] set_display evaluation order doesn't match documented behaviour

ar', 1: 'baz'} >>> print(foo) {True: 'baz'} Note that I've tagged this as a documentation bug, but it seems like the documentation might be the preferred implementation. -- assignee: docs@python components: Documentation messages: 257579 nosy: Hamish Campbell, docs@python priori

[issue26020] set_display evaluation order doesn't match documented behaviour

Hamish Campbell added the comment: Note also the differences here: >>> print(set([True, 1])) {True} >>> print({True, 1}) {1} >>> print({x for x in [True, 1]}) {True} -- ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Hamish Campbell added the comment: Apologies, that first line should read "It looks like the documentation of set displays do not match behaviour in some cases". -- ___ Python tracker

[issue26020] set_display evaluation order doesn't match documented behaviour

Emanuel Barry added the comment: Set displays appear to be the culprit here: >>> class A: ... count = 0 ... def __init__(self): ... self.cnt = self.count ... type(self).count += 1 ... def __eq__(self, other): ... return type(self) is type(other) ... def __hash__(self): ...

[issue26020] set_display evaluation order doesn't match documented behaviour

Changes by Raymond Hettinger : -- keywords: +patch Added file: http://bugs.python.org/file41514/build_set.diff ___ Python tracker

Re: Evaluation order

Le vendredi 10 juillet 2015 04:02:56 UTC+2, Chris Angelico a écrit : I'm not sure what contradiction you're referring to, here. The evaluation that you're pointing out says, as Terry showed via the disassembly, that Python's first action is to look up the name 't' and grab a reference to

Re: Evaluation order

On 7/10/2015 8:04 AM, candide wrote: Le vendredi 10 juillet 2015 04:02:56 UTC+2, Chris Angelico a écrit : I'm not sure what contradiction you're referring to, here. The evaluation that you're pointing out says, as Terry showed via the disassembly, that Python's first action is to look up the

Re: Evaluation order

Hi, No, the value of t is a reference to tje list. So first, (1) the value of the reference t is recovered, (2) the parenthesis is evaluated, (...) the whole expression is evaluated. To evaluate (2), the .sort() call is executed in place with the side effect of sorting the content of t. t.sort()

Re: Evaluation order

Hi, No, the value of t is a reference to tje list. So first, (1) the value of the reference t is recovered, (2) the parenthesis is evaluated, (...) the whole expression is evaluated. To evaluate (2), the .sort() call is executed in place with the side effect of sorting the content of t. t.sort()

Re: Evaluation order

On Friday, July 10, 2015 at 8:04:36 AM UTC-4, candide wrote: Le vendredi 10 juillet 2015 04:02:56 UTC+2, Chris Angelico a écrit : I'm not sure what contradiction you're referring to, here. The evaluation that you're pointing out says, as Terry showed via the disassembly, that

Re: Evaluation order

On Fri, Jul 10, 2015 at 10:04 PM, candide c.cand...@laposte.net wrote: But in order to perform an operation, the interpreter has to evaluate the operands and evaluating is not grabbing a reference to. Actually, it is. Suppose that instead of 't', you had a function call: def get_t(announce,

Re: Evaluation order

Anyway, if we enter this kind of discussion, it is a reliable indication that the code smells. There is a pythonic way to express the same task: t.sort() t kind regards Thierry On ven., juil. 10, 2015 at 2:28 PM, Terry Reedy tjre...@udel.edu [tjre...@udel.edu] wrote: On 7/10/2015 8:04 AM,

Re: Evaluation order

On 10/07/2015 15:30, Thierry Chappuis wrote: [snipped] Please don't top post here as it can get irritating, especially in long threads, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --

Re: Evaluation order

On 7/9/2015 8:10 PM, candide wrote: The official doc explains that : Python evaluates expressions from left to right. cf. https://docs.python.org/3.3/reference/expressions.html#evaluation-order But consider the following snippet : t=[2020, 42, 2015] t*(1+int(bool(t.sort( [42, 2015

Re: Evaluation order

On Fri, Jul 10, 2015 at 10:10 AM, candide c.cand...@laposte.net wrote: The official doc explains that : Python evaluates expressions from left to right. cf. https://docs.python.org/3.3/reference/expressions.html#evaluation-order But consider the following snippet : t=[2020, 42, 2015] t

Evaluation order

The official doc explains that : Python evaluates expressions from left to right. cf. https://docs.python.org/3.3/reference/expressions.html#evaluation-order But consider the following snippet : t=[2020, 42, 2015] t*(1+int(bool(t.sort( [42, 2015, 2020] Is there not some

[issue11205] Evaluation order of dictionary display is different from reference manual.

Steve Dougherty added the comment: Anyone care to review issue11205-v3.patch ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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?

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- priority: low - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue23316] Incorrect evaluation order of function arguments with *args

Terry J. Reedy added the comment: I expect left to right as documented (and designed by Guido). His OK or clarification would be to intentionally do differently. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: After thinking about this a bit more, my suggestion is not to fix it. Instead, I suggest that PEP 8 be modified to suggest that all positional arguments and iterable argument unpackings precede keyword arguments and keyword argument unpackings. Then, a tool

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: (I also suggest that the evaluation order within a function argument list to be defined to be positional and iterable before keyword, otherwise left-to-right —  rather than strictly left-to-right). -- ___ Python

[issue23316] Incorrect evaluation order of function arguments with *args

SilentGhost added the comment: It seems, if I read https://docs.python.org/3/reference/expressions.html#calls correctly that the evaluation order of the function arguments is not defined in general, as it depends on your use of keyword argument and exact function signature. Naturally, f

[issue23316] Incorrect evaluation order of function arguments with *args

R. David Murray added the comment: The resolution of issue 16967 argues that this should probably be considered a bug. It certainly goes against normal Python expectations. I think it should also be considered to be of low priority, though. -- nosy: +r.david.murray priority: normal

[issue23316] Incorrect evaluation order of function arguments with *args

New submission from Joshua Landau: It is claimed that all expressions are evaluated left-to-right, including in functions¹. However, f(*a(), b=b()) will evaluate b() before a(). ¹ https://docs.python.org/3/reference/expressions.html#evaluation-order -- components: Interpreter

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: actually, we accept alternation, so maybe a bit to say whether we start with a list or a dict followed by a length of the alternating sequence? -- ___ Python tracker rep...@bugs.python.org

[issue23316] Incorrect evaluation order of function arguments with *args

R. David Murray added the comment: Neil: I presume you are speaking of your in-progress PEP patch, and not the current python code? If so, please keep the discussion of handling this in the context of the PEP to the PEP issue. This issue should be for resolving the bug in the current code

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: Yes, sorry David. I got linked here from the other issue. In any case, in the current code, the longest alternating sequence possible is 4. So one way to solve this is to change the CALL_FUNCTION parameters to be lists and dicts only and then process the

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: another option is to add a LIST_EXTEND(stack_difference) opcode that would allow us to take the late iterable and extend a list at some arbitrary stack position. I had to add something like that for dicts for the other issue, so it would follow that pattern.

[issue23316] Incorrect evaluation order of function arguments with *args

Neil Girdhar added the comment: I assume this is the problem: dis.dis('f(*a(), b=b())') 1 0 LOAD_NAME0 (f) 3 LOAD_NAME1 (a) 6 CALL_FUNCTION0 (0 positional, 0 keyword pair) 9 LOAD_CONST

[issue19657] List comprehension conditional evaluation order seems backwards

generating a value could in fact be very expensive, whereas determining whether or not a precondition has been met should be less expensive. What could/should be done is one of two things: 1. evaluation order should be clearly spelled out in the docs, or 2. the list comprehension handling code should

[issue19657] List comprehension conditional evaluation order seems backwards

Peter Otten added the comment: I believe you are misinterpreting what you are seeing. Empty lines read from a file do not produce an empty string, you get \n instead which is true in a boolean context. Try [line.split()[0] for line in lines if line.strip() and not line.startswith(#)] or add

[issue19657] List comprehension conditional evaluation order seems backwards

Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - invalid stage: - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19657

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

Re: baffled classes within a function namespace. Evaluation order.

On Fri, 26 Apr 2013 07:39:32 +0200, Peter Otten wrote: A class body is basically a function body that is executed once. To allow an assignment x = 42 class A: ... x = x ... which is not possible inside a function As far as I can tell, the documentation says that this assignment

Re: baffled classes within a function namespace. Evaluation order.

Steven D'Aprano wrote: On Fri, 26 Apr 2013 07:39:32 +0200, Peter Otten wrote: A class body is basically a function body that is executed once. To allow an assignment x = 42 class A: ... x = x ... which is not possible inside a function As far as I can tell, the

Re: baffled classes within a function namespace. Evaluation order.

On Fri, 26 Apr 2013 09:15:51 +0200, Peter Otten wrote: Define a global variable x and run it again. I don't have an ancient Python lying around but my prediction is x = 42 f().x 42 which would be the same behaviour as that of Python 3.3. /facepalm You're absolutely right. Sorry for

baffled classes within a function namespace. Evaluation order.

I am completely baffled by the behavior of this code with regards to the evaluation order of namespaces when assigning the class attributes. Both classes are nested within a function I called whywhywhy. I assumed that example1 and example2 classes would look first at their own namespace

Re: baffled classes within a function namespace. Evaluation order.

On Thursday, April 25, 2013 11:27:37 PM UTC+2, Alastair Thompson wrote: I am completely baffled by the behavior of this code with regards to the evaluation order of namespaces when assigning the class attributes.  Both classes are nested within a function I called whywhywhy. [snip weird

Re: baffled classes within a function namespace. Evaluation order.

Thats a good pointer to what is going on. Thank you Bas. I am familiar with error such as x=1 def foo(): x = 2 def erm(): print(x) x=3 erm() foo() UnboundLocalError: local variable 'x' referenced before assignment. It seems a bit different for classes (below), as it

Re: baffled classes within a function namespace. Evaluation order.

Alastair Thompson wrote: I am completely baffled by the behavior of this code with regards to the evaluation order of namespaces when assigning the class attributes. Both classes are nested within a function I called whywhywhy. I assumed that example1 and example2 classes would look first

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

[issue16777] Evaluation order doc section is wrong about dicts

New submission from Ezio Melotti: http://docs.python.org/2/reference/expressions.html#evaluation-order says that the dicts are evaluated in this order: {expr1: expr2, expr3: expr4} however each value is evaluated before the respective key: def f(x): print(x) return x {f('k1'): f('v1'), f

[issue16777] Evaluation order doc section is wrong about dicts

Ezio Melotti added the comment: This has already been reported in #11205. -- resolution: - duplicate stage: needs patch - committed/rejected status: open - closed superseder: - Evaluation order of dictionary display is different from reference manual

[issue11205] Evaluation order of dictionary display is different from reference manual.

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

  1   2   >