On Sun, 5 May 2013 15:27:36 -0700
Eli Bendersky eli...@gmail.com wrote:
As for pickling enums created with the functional API, I don't think we now
provide less than the pickle module dictates in the general sense. The
pickle docs say:
Next time, please try reading the message(s) you are
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
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
On Mon, May 6, 2013 at 6:46 PM, Armin Rigo ar...@tunes.org 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
Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan ncogh...@gmail.com 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
On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan ncogh...@gmail.com 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
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
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 behavior
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 nicely
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
On Mon, 6 May 2013 15:59:49 +0200 (CEST)
nick.coghlan python-check...@python.org wrote:
http://hg.python.org/cpython/rev/f65b867ce817
changeset: 83644:f65b867ce817
user:Nick Coghlan ncogh...@gmail.com
date:Mon May 06 23:59:20 2013 +1000
summary:
Issue #11816: multiple
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 of
On 6 May 2013 20:46, Steve Dower steve.do...@microsoft.com 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
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
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 shibt...@gmail.com 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
On Mon, May 6, 2013 at 4:46 AM, Armin Rigo ar...@tunes.org 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
On 5/6/2013 10:20 AM, Nick Coghlan wrote:
On Mon, May 6, 2013 at 11:26 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Mon, 6 May 2013 23:18:54 +1000,
Nick Coghlan ncogh...@gmail.com a écrit :
We're not going to change the language design because people don't
understand the difference between
On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy tjre...@udel.edu 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,
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 or
On 5/6/2013 6:34 PM, Antoine Pitrou wrote:
On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy tjre...@udel.edu 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,
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
On 7 May 2013 12:29, Ethan Furman et...@stoneleaf.us 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 = ...
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
On Mon, May 6, 2013 at 7:50 PM, Terry Jan Reedy tjre...@udel.edu wrote:
On 5/6/2013 6:34 PM, Antoine Pitrou wrote:
On Mon, 06 May 2013 18:23:02 -0400
Terry Jan Reedy tjre...@udel.edu wrote:
'Item' is necessarily left vague for mutable sequences as bytearrays
also store values. The fact
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__
On 5/6/2013 7:58 PM, Tim Delaney wrote:
On 7 May 2013 12:29, Ethan Furman et...@stoneleaf.us
mailto:et...@stoneleaf.us 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
On 7 May 2013 15:14, Tim Delaney timothy.c.dela...@gmail.com 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
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
On 7 May 2013 15:14, Tim Delaney timothy.c.dela...@gmail.com 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 module
class
On 7 May 2013 14:54, Ethan Furman et...@stoneleaf.us 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
30 matches
Mail list logo
