Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, 06 May 2013 22:50:55 -0400 Terry Jan Reedy wrote: > > > A bytearray or a array.array may indeed store values, but a list stores > > references to > > objects. > > I said exactly that in reference to CPython. As far as I know, the same > is true of lists in every other implementation up

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 7 May 2013 14:54, Ethan Furman wrote: > On 05/06/2013 07:58 PM, Tim Delaney wrote: > >> >> Considering that doesn't actually work with the reference implementation >> (AutoNumber.__new__ is never called) ... no. >> > > Two points: > > 1) Did you grab the latest code? That exact implementati

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 7 May 2013 15:14, Tim Delaney wrote: > Unfortunately, if you subclass AutoNumber from IntEnum it breaks. > > -- Run Python3 -- > Traceback (most recent call last): > File "D:\home\repos\mercurial\ref435\ref435.py", line 346, in > class Color(AutoNumber): > File "D:\hom

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 05/06/2013 08:35 PM, Glenn Linderman wrote: N.B. In your latest ref435.py code, line 105, should be "An Enum class _is_ final..." rather than "in". Thanks, fixed. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 7 May 2013 15:14, Tim Delaney wrote: > D'oh! I had my default path being my forked repo ... so didn't see the > changes. BTW I can't see how that exact implementation passes ... not > enough parameters declared in AutoNumber.__new__ ... > Sorry - my fault again - I'd already changed () to ...

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 5/6/2013 7:58 PM, Tim Delaney wrote: On 7 May 2013 12:29, Ethan Furman > wrote: On 05/05/2013 02:55 PM, Tim Delaney wrote: So long as I can get one of the requirements documented to implement an auto-number syntax I'll be happy enough with

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 05/06/2013 07:58 PM, Tim Delaney wrote: Considering that doesn't actually work with the reference implementation (AutoNumber.__new__ is never called) ... no. Two points: 1) Did you grab the latest code? That exact implementation passes in the tests. 2) You can write your __new__ ho

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy wrote: > On 5/6/2013 6:34 PM, Antoine Pitrou wrote: > >> On Mon, 06 May 2013 18:23:02 -0400 >> Terry Jan Reedy wrote: >> >>> >>> 'Item' is necessarily left vague for mutable sequences as bytearrays >>> also store values. The fact that Antoine's exa

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 5/6/2013 6:26 PM, Ethan Furman wrote: On 05/05/2013 01:01 AM, Glenn Linderman wrote: The bigger problem is that the arithmetic on enumeration items, which seems like it should be inherited from NamedInt (and seems to be, because the third value from each print is a NamedInt), doesn't pick

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 7 May 2013 12:29, Ethan Furman wrote: > On 05/05/2013 02:55 PM, Tim Delaney wrote: > >> >> So long as I can get one of the requirements documented to implement an >> auto-number syntax I'll be happy enough with >> stdlib enums I think. >> >> class Color(AutoIntEnum): >> red = ... >>

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 05/05/2013 02:55 PM, Tim Delaney wrote: So long as I can get one of the requirements documented to implement an auto-number syntax I'll be happy enough with stdlib enums I think. class Color(AutoIntEnum): red = ... green = ... blue = ... Will this do? class AutoNumber

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On 5/6/2013 6:34 PM, Antoine Pitrou wrote: On Mon, 06 May 2013 18:23:02 -0400 Terry Jan Reedy wrote: 'Item' is necessarily left vague for mutable sequences as bytearrays also store values. The fact that Antoine's example 'works' for bytearrays is an artifact of the caching, not a language-mand

Re: [Python-Dev] PEP 435 - ref impl disc 2

On 05/05/2013 01:01 AM, Glenn Linderman wrote: The bigger problem is that the arithmetic on enumeration items, which seems like it should be inherited from NamedInt (and seems to be, because the third value from each print is a NamedInt), doesn't pick up "x" or "y", nor does it pick up "the-x"

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, 06 May 2013 18:23:02 -0400 Terry Jan Reedy wrote: > > 'Item' is necessarily left vague for mutable sequences as bytearrays > also store values. The fact that Antoine's example 'works' for > bytearrays is an artifact of the caching, not a language-mandated > necessity. No, it isn't. You

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On 5/6/2013 10:20 AM, Nick Coghlan wrote: On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou wrote: Le Mon, 6 May 2013 23:18:54 +1000, Nick Coghlan a écrit : We're not going to change the language design because people don't understand the difference between "is" and "==" For sure. The definit

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, May 6, 2013 at 4:46 AM, Armin Rigo wrote: > This is clearly a language design issue though. I can't really think > of a use case that would break if we relax the requirement, but I > might be wrong. It seems to me that at most some modules like pickle > which use id()-keyed dictionaries

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

As the PEP author I declare we can have 3-letter extensions. It is not a big deal. Daniel Holth On Mon, May 6, 2013 at 4:30 PM, Richard Oudkerk wrote: > So the bug would just cause .pyzw files to be opened with py instead of pyw? > Won't this be harmless? > > I think the worst that would happen

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

So the bug would just cause .pyzw files to be opened with py instead of pyw? Won't this be harmless? I think the worst that would happen would be that you get a redundant console window if you are not already running powershell inside a console. -- Richard __

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 6 May 2013 20:46, Steve Dower wrote: > To summarise the bug, when PowerShell invokes a command based on an > extension in PATHEXT, only the first three characters of the extension are > used to determine the associated program. I tested this by creating a file > "test.txta" and adding ".TXTA"

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

> From: Nick Coghlan [mailto:ncogh...@gmail.com] > Sent: Friday, May 3, 2013 2348 > > We don't need examples of arbitrary data file extentions, we need examples > of 4 letter extensions that are known to work correctly when placed on > PATHEXT, including when called from PowerShell. In the absence

Re: [Python-Dev] cpython: Issue #11816: multiple improvements to the dis module

On Mon, 6 May 2013 15:59:49 +0200 (CEST) nick.coghlan wrote: > http://hg.python.org/cpython/rev/f65b867ce817 > changeset: 83644:f65b867ce817 > user:Nick Coghlan > date:Mon May 06 23:59:20 2013 +1000 > summary: > Issue #11816: multiple improvements to the dis module > > * get

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

On 05/06/2013 10:48 AM, Georg Brandl wrote: Am 05.05.2013 22:09, schrieb Ethan Furman: About the closest you going to be able to get is something like: def e(_next=[1]): e, _next[0] = _next[0], _next[0] + 1 return e class Color(Enum): red = e() green = e() blue =

Re: [Python-Dev] PEP 435: initial values must be specified? Yes

Am 05.05.2013 22:09, schrieb Ethan Furman: > About the closest you going to be able to get is something like: > > def e(_next=[1]): > e, _next[0] = _next[0], _next[0] + 1 > return e > > class Color(Enum): > red = e() > green = e() > blue = e() Uh, that's surely more nic

Re: [Python-Dev] PEP 435 - requesting pronouncement

On May 05, 2013, at 06:44 AM, Ethan Furman wrote: > to easily create enums when prototyping or at the interactive prompt (I'll > use it all the time -- it's convenient! ;) +1billion (That's literally the number of times I've used the functional API when discussion various aspects of enum behavio

Re: [Python-Dev] PEP 435 - ref impl disc 2

On May 06, 2013, at 02:51 PM, Nick Coghlan wrote: >Enums are the same - they carve out a subtree in the type hierarchy >that *doesn't* behave the same as the standard tree anchored directly >on type. This *is* going to cause conflicts with meta-tools that only >handle ordinary types - the trick is

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou wrote: > Le Mon, 6 May 2013 23:18:54 +1000, > Nick Coghlan a écrit : >> We're not going to change the language design because people don't >> understand the difference between "is" and "==" and then wrongly blame >> PyPy for breaking their code. > >

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

Le Mon, 6 May 2013 23:18:54 +1000, Nick Coghlan a écrit : > > IIRC, Jython just delays calculating the object id() until it is > called, and lives with it potentially being incredibly expensive to > calculate. Is there some way PyPy can run with a model where "is" is > defined in terms of values

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On Mon, May 6, 2013 at 6:46 PM, Armin Rigo wrote: > This is clearly a language design issue though. I can't really think > of a use case that would break if we relax the requirement, but I > might be wrong. It seems to me that at most some modules like pickle > which use id()-keyed dictionaries

Re: [Python-Dev] Fighting the theoretical randomness of "is" on immutables

On 5/6/2013 4:46 AM, Armin Rigo wrote: 'is' *is* well-defined. In production code, the main use of 'is' is for builtin singletons, the bool doubleton, and object instances used as sentinals. The most common use, in particular, is 'if a is None:'. For such code, the result must be independent o

[Python-Dev] Fighting the theoretical randomness of "is" on immutables

Hi all, In the context PyPy, we've recently seen again the issue of "x is y" not being well-defined on immutable constants. I've tried to summarize the issues and possible solutions in a mail to pypy-dev [1] and got some answers already. Having been convinced that the core is a language design i