Re: [Python-Dev] async __setitem__
On Sun, Jun 21, 2015 at 12:48 AM, Greg Ewing wrote: > Nick Coghlan wrote: > >> What if we're assigning to >> multiple targets, do the run in parallel? How is tuple unpacking >> handled? How is augmented assignment handled? >> >> If we allow asynchronous assignment, do we allow asynchronous deletion as >> well? >> > > Yeah, we'd kind of be letting the camel's nose in > here. There's no obvious place to stop until *every* > dunder method has an async counterpart. Exactly. We should not go here at all. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 490: Chain exceptions at C level
On Sat, 20 Jun 2015 21:16:48 +0200 "M.-A. Lemburg" wrote: > On 20.06.2015 09:30, Victor Stinner wrote: > > Hi, > > > > I didn't get much feedback on this PEP. Since the Python 3.6 branch is > > open (default), it's probably better to push such change in the > > beginning of the 3.6 cycle, to catch issues earlier. > > > > Are you ok to chain exceptions at C level by default? > > I think it's a good idea to make C APIs available to > simplify chaining exceptions at the C level, but don't > believe that always doing this by default is a good idea. > It should really be a case-by-case decision, IMO. > > Note that Python exceptions are cheap to raise in C > (very much unlike in Python), so making this more > expensive by default would introduce a significant > overhead - without much proven benefit. I agree with Marc-André. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unbound locals in class scopes
On 20 June 2015 at 18:39, Ron Adam wrote: > > > On 06/20/2015 12:12 PM, Ron Adam wrote: > >> >> >> On 06/20/2015 02:51 AM, Ivan Levkivskyi wrote: >> > > Guido said 13 years ago that this behavior should not be changed: >>> https://mail.python.org/pipermail/python-dev/2002-April/023428.html, >>> however, things changed a bit in Python 3.4 with the introduction of the >>> LOAD_CLASSDEREF opcode. I just wanted to double-check whether it is >>> still a >>> desired/expected behavior. >>> >> > Guido's comment still stands as far as references inside methods work in >> regards to the class body. (they must use a self name to access the class >> name space.) But the execution of the class body does use lexical scope, >> otherwise it would print xtop instead of xlocal here. >> > > Minor corrections: > > Methods can access but not write to the class scope without using self. > So that is also equivalent to the function version using type(). The > methods capture the closure they were defined in, which is interesting. > > And the self name refers to the object's names space not the class name > space. It is still not clear whether Guido's comment still stands for not raising an UnboundLocalError in class definitions but using globals instead. This is the only questionable point for me currently. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unbound locals in class scopes
On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi wrote: > It is still not clear whether Guido's comment still stands for not raising > an UnboundLocalError in class definitions but using globals instead. > Can you phrase this in the form of an example, showing what it currently does and what you think it should do, instead? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unbound locals in class scopes
On 21 June 2015 at 22:05, Guido van Rossum wrote: > > On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi wrote: >> >> It is still not clear whether Guido's comment still stands for not raising an UnboundLocalError in class definitions but using globals instead. > > > Can you phrase this in the form of an example, showing what it currently does and what you think it should do, instead? > Here is an example: x = "xtop" y = "ytop" def func(): x = "xlocal" y = "ylocal" class C: print(x) print(y) y = 1 func() prints xlocal ytop Intuitively, one might think that it should raise UnboundLocalError or print ylocal instead of ytop. This question was discussed 13 years ago and then you said that this lookup in globals is an intentional behavior. This behavior is not documented, and I started an issue on bug tracker about documenting it. Then, Eric proposed to ask you again, whether this is still an intentional behavior. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unbound locals in class scopes
On 22 June 2015 at 08:46, Ivan Levkivskyi wrote: > > > On 21 June 2015 at 22:05, Guido van Rossum wrote: >> >> On Sun, Jun 21, 2015 at 6:22 PM, Ivan Levkivskyi >> wrote: >>> >>> It is still not clear whether Guido's comment still stands for not >>> raising an UnboundLocalError in class definitions but using globals instead. >> >> >> Can you phrase this in the form of an example, showing what it currently >> does and what you think it should do, instead? >> > > Here is an example: > > x = "xtop" > y = "ytop" > def func(): > x = "xlocal" > y = "ylocal" > class C: > print(x) > print(y) > y = 1 > func() > > prints > > xlocal > ytop > > Intuitively, one might think that it should raise UnboundLocalError or print > ylocal instead of ytop. > This question was discussed 13 years ago and then you said that this lookup > in globals > is an intentional behavior. > > This behavior is not documented, and I started an issue on bug tracker > about documenting it. > Then, Eric proposed to ask you again, whether this is still an intentional > behavior. Diving into some bytecode details: We added LOAD_CLASSDEREF (https://docs.python.org/3/library/dis.html#opcode-LOAD_CLASSDEREF) a while back to account for the fact that __prepare__ may inject locals into a class body that the compiler doesn't know about. Unlike LOAD_DEREF, LOAD_CLASSDEREF checks the locals before it checks the closure cell. However, neither LOAD_CLASSDEREF *nor* LOAD_DEREF is used for names that are *assigned* in the class body - those get flagged as local variables, so we end up emitting LOAD_NAME for them, and hence ignore any nonlocal variables with that name. If a module global or builtin exists, we'll find that, otherwise we'll throw NameError. With nested_scopes having been the default since 2.2, and accounting for the fact that folks *do* write code like "name = name" at class scope and expect it to "do the right thing", it seems reasonable to me to just make this work properly, rather than having to explain why it doesn't work as one might expected based on the behaviour of module level class definitions and other references to nonlocal variables from a class body. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
