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
On Sun, 5 May 2013 15:27:36 -0700
Eli Bendersky 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 replying to befo
On Sun, May 5, 2013 at 4:15 PM, Ethan Furman wrote:
> On 05/05/2013 03:16 PM, Nikolaus Rath wrote:
>>
>> Guido van Rossum writes:
1. Having to enter the values is annoying. Sorry, I read the rationale
and
all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
On 05/05/2013 03:16 PM, Nikolaus Rath wrote:
Guido van Rossum writes:
1. Having to enter the values is annoying. Sorry, I read the rationale and
all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
expect to edit and reorder enums (if I ever use them) and get irritated with
Guido van Rossum writes:
>> 1. Having to enter the values is annoying. Sorry, I read the rationale and
>> all that, and I *still* want to write a C-Like enum { A, B, C }. I fully
>> expect to edit and reorder enums (if I ever use them) and get irritated with
>> having to update the value assignmen
On Sun, May 5, 2013 at 10:46 AM, Antoine Pitrou wrote:
> On Sun, 5 May 2013 07:09:14 -0700
> Eli Bendersky wrote:
> > On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou
> wrote:
> >
> > > On Sat, 4 May 2013 15:04:49 -0700
> > > Eli Bendersky wrote:
> > > > Hello pydev,
> > > >
> > > > PEP 435 is r
On 5 May 2013 18:49, Guido van Rossum wrote:
> > Summary - good job, I like the PEP a lot. But Python's enums are very
> unlike
>
> those of other languages, and I suspect that's going to be more of an
> issue
> > than you'd hope...
>
> We're pretty confident that we're doing about the best job p
On 06/05/13 03:07, Charles-François Natali wrote:
I'm chiming in late, but am I the only one who's really bothered by the syntax?
class Color(Enum):
red = 1
green = 2
blue = 3
I really don't see why one has to provide values, since an enum
constant *is* the value.
In many cases,
On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou wrote:
> I still would like to see Nick's class-based API preferred over the
> functional API:
>
>class Season(Enum, members='spring summer autumn'):
> pass
>
> The PEP doesn't even mention it, even though you got significant
> pushback on t
On Sun, May 5, 2013 at 10:41 AM, Paul Moore wrote:
> OK, I thought I'd take a look. I have never particularly needed enums in
> real life, so I'm reading the PEP from the POV of a naive user who is just
> thinking "hey, neat, Python got enums, let's see how they work". I have been
> skimming the d
This has all long been hashed out, and I've pronounced on this
already. I'm sorry you weren't there for the bikeshedding, but nothing
you say here is new and it was all considered carefully.
On Sun, May 5, 2013 at 10:07 AM, Charles-François Natali
wrote:
> I'm chiming in late, but am I the only o
I am fine with adding more information about this issue to the PEP. I
am not fine with reopening the issue. I really, really, really have
looked at it from all sides and the current design of the functional
API has my full blessing.
On Sun, May 5, 2013 at 10:46 AM, Antoine Pitrou wrote:
> On Sun,
On Sun, 5 May 2013 07:09:14 -0700
Eli Bendersky wrote:
> On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou wrote:
>
> > On Sat, 4 May 2013 15:04:49 -0700
> > Eli Bendersky wrote:
> > > Hello pydev,
> > >
> > > PEP 435 is ready for final review. A lot of the feedback from the last
> > few
> > > wee
OK, I thought I'd take a look. I have never particularly needed enums in
real life, so I'm reading the PEP from the POV of a naive user who is just
thinking "hey, neat, Python got enums, let's see how they work". I have
been skimming the discussions and my head has been exploding with the
complexit
I'm chiming in late, but am I the only one who's really bothered by the syntax?
class Color(Enum):
red = 1
green = 2
blue = 3
I really don't see why one has to provide values, since an enum
constant *is* the value.
In many cases, there's no natural mapping between an enum constant and
On May 5, 2013, at 6:44 AM, Ethan Furman wrote:
> On 05/05/2013 03:05 AM, Antoine Pitrou wrote:
>> I still would like to see Nick's class-based API preferred over the
>> functional API:
>>
>>class Season(Enum, members='spring summer autumn'):
>> pass
>>
>> The PEP doesn't even mention
On Sun, May 5, 2013 at 3:05 AM, Antoine Pitrou wrote:
> On Sat, 4 May 2013 15:04:49 -0700
> Eli Bendersky wrote:
> > Hello pydev,
> >
> > PEP 435 is ready for final review. A lot of the feedback from the last
> few
> > weeks of discussions has been incorporated.
>
> I still would like to see Nic
I'm unhappy with this API. I never used it. It is also more verbose than
the functional API.
Victor
Le dimanche 5 mai 2013, Antoine Pitrou a écrit :
> On Sat, 4 May 2013 15:04:49 -0700
> Eli Bendersky > wrote:
> > Hello pydev,
> >
> > PEP 435 is ready for final review. A lot of the feedback from
On 05/05/2013 03:05 AM, Antoine Pitrou wrote:
On Sat, 4 May 2013 15:04:49 -0700
Eli Bendersky wrote:
Hello pydev,
PEP 435 is ready for final review. A lot of the feedback from the last few
weeks of discussions has been incorporated.
I still would like to see Nick's class-based API preferred
On Sun, 05 May 2013 20:59:03 +1000
Steven D'Aprano wrote:
> On 05/05/13 20:05, Antoine Pitrou wrote:
>
> > I still would like to see Nick's class-based API preferred over the
> > functional API:
> >
> > class Season(Enum, members='spring summer autumn'):
> >pass
>
> -1
>
> As alread
On 05/05/13 20:05, Antoine Pitrou wrote:
I still would like to see Nick's class-based API preferred over the
functional API:
class Season(Enum, members='spring summer autumn'):
pass
-1
As already mentioned, this is no substitute for the functional API as it is a
statement, not an
Antoine Pitrou, 05.05.2013 12:05:
> On Sat, 4 May 2013 15:04:49 -0700
> Eli Bendersky wrote:
>> PEP 435 is ready for final review. A lot of the feedback from the last few
>> weeks of discussions has been incorporated.
>
> I still would like to see Nick's class-based API preferred over the
> functi
On Sat, 4 May 2013 15:04:49 -0700
Eli Bendersky wrote:
> Hello pydev,
>
> PEP 435 is ready for final review. A lot of the feedback from the last few
> weeks of discussions has been incorporated.
I still would like to see Nick's class-based API preferred over the
functional API:
class Season(
On Sat, May 4, 2013 at 8:22 PM, Tim Delaney wrote:
> On 5 May 2013 13:11, Tim Delaney wrote:
>
>> @@ -142,6 +152,7 @@
>> if obj_type in (object, Enum):
>> enum_item = object.__new__(enum_class)
>> else:
>> +value = obj_typ
On 5 May 2013 13:32, Ethan Furman wrote:
> On 05/04/2013 08:11 PM, Tim Delaney wrote:
>
>>
>> I've been able to achieve the auto-numbering without relying on the
>> internal implementation at all (with a
>> limitation), with a single change to enum_type.__new__. My previous patch
>> was slightl
On 05/04/2013 08:11 PM, Tim Delaney wrote:
I've been able to achieve the auto-numbering without relying on the internal
implementation at all (with a
limitation), with a single change to enum_type.__new__. My previous patch was
slightly wrong - fix below as well. All
existing tests pass. BTW
On 5 May 2013 13:11, Tim Delaney wrote:
> @@ -142,6 +152,7 @@
> if obj_type in (object, Enum):
> enum_item = object.__new__(enum_class)
> else:
> +value = obj_type.__new__(obj_type, value)
> enum_item
On 5 May 2013 11:22, Tim Delaney wrote:
> On 5 May 2013 10:49, Eli Bendersky wrote:
>
>>
>> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
>> wrote:
>>
>>> Typo line 171:
>>>
>>>
>> Fixed, thanks.
>>
>>
>>
>>> One thing I'd like to be clear in the PEP about is whether enum_type and
>>> _EnumDict.
On 5 May 2013 10:49, Eli Bendersky wrote:
>
> On Sat, May 4, 2013 at 4:27 PM, Tim Delaney
> wrote:
>
>> Typo line 171:
>>
>>
> Fixed, thanks.
>
>
>
>> One thing I'd like to be clear in the PEP about is whether enum_type and
>> _EnumDict._enum_names should be documented, or whether they're consi
On Sat, May 4, 2013 at 4:27 PM, Tim Delaney wrote:
> Typo line 171:
>
>
Fixed, thanks.
> One thing I'd like to be clear in the PEP about is whether enum_type and
> _EnumDict._enum_names should be documented, or whether they're considered
> implementation details.
>
>
No, they should not. Not o
Typo line 171:
One thing I'd like to be clear in the PEP about is whether enum_type and
_EnumDict._enum_names should be documented, or whether they're considered
implementation details.
I'd like to make a subclass of Enum that accepts ... for auto-valued enums
but that requires subclassing the m
Great job guys.
Victor
Le 5 mai 2013 00:06, "Eli Bendersky" a écrit :
> Hello pydev,
>
> PEP 435 is ready for final review. A lot of the feedback from the last few
> weeks of discussions has been incorporated. Naturally, not everything could
> go in because some minor (mostly preference-based) i
Hello pydev,
PEP 435 is ready for final review. A lot of the feedback from the last few
weeks of discussions has been incorporated. Naturally, not everything could
go in because some minor (mostly preference-based) issues did not reach a
consensus. We do feel, however, that the end result is bette
33 matches
Mail list logo
