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 5/5/2013 9:51 PM, Nick Coghlan wrote:
On Mon, May 6, 2013 at 12:46 PM, Glenn Linderman wrote:
Sadly, once the Enums are defined, there is to be no way to subclass them to
add functionality, like producing a NamedInt result from operations on them.
That rule is enforced by the metaclass, so.
On Mon, May 6, 2013 at 12:46 PM, Glenn Linderman wrote:
> Sadly, once the Enums are defined, there is to be no way to subclass them to
> add functionality, like producing a NamedInt result from operations on them.
That rule is enforced by the metaclass, so... ;)
Custom metaclasses are amazingly
On 5/5/2013 7:14 PM, Nick Coghlan wrote:
I think there comes a point where "subclass the metaclass" is the
right answer to "how do I do X with this type?". I believe making two
different kinds of value labelling mechanisms play nice is such a case
:)
Could be.
Could be that sufficient operator
On Mon, May 6, 2013 at 8:57 AM, Glenn Linderman wrote:
> So you asked why would I want to put a named object as the value of
> something else with a name... maybe Enum should make provision for that...
> if the primary type ( Int for IntEnum, NamedInt for NamedIntEnum) happens to
> have a __name__
On 05/05/2013 04:57 PM, Greg Ewing wrote:
Ethan Furman wrote:
--> class Color(Enum):
... red, green, blue
...
--> class MoreColor(Color):
... red, orange, yellow
...
--> type(MoreColor.red) is MoreColor
False
This argument no longer applies, since we're not
allowing enums to be exten
On 05/05/2013 04:14 PM, Tim Delaney wrote:
1. That the dictionary returned from .__prepare__ provide a way
to obtain the enum instance names
once it's been populated (e.g. once it's been passed as the classdict to
__new__). The reference implementation
provides a _enum_names list attribute. Th
Ethan Furman wrote:
--> class Color(Enum):
... red, green, blue
...
--> class MoreColor(Color):
... red, orange, yellow
...
--> type(MoreColor.red) is MoreColor
False
This argument no longer applies, since we're not
allowing enums to be extended.
class Color(Enum):
red = e()
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
> >> It was mentioned in the other threads, but the requirement is either:
> >>
> >> 1. That the dictionary returned from .__prepare__
> provide
> >> a way to obtain the enum instance names once it's been populated (e.g.
> once
> >> it's been passed as the classdict to __new__). The reference
> imp
On 5 May 2013 21:58, Tim Delaney wrote:
> On 5 May 2013 16:17, Ethan Furman wrote:
>
>> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>>
>>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>>
2. Instead of directly setting the _name and _value of the enum_item,
it lets the Enum class do it v
On May 05, 2013, at 03:43 PM, Guido van Rossum wrote:
>I'll let Eli or Ethan respond to this. It sounds fine to me to support
>you with some kind of hook in the spec, even though I personally would
>rather assign my enum values explicitly (I'm old-fashioned that way
>:-).
Assuming the picklabilit
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
On 6 May 2013 08:55, Eli Bendersky wrote:
> 1. That the dictionary returned from .__prepare__ provide
> a way to obtain the enum instance names once it's been populated (e.g. once
> it's been passed as the classdict to __new__). The reference implementation
> provides a _enum_names list attribute
On Sun, May 5, 2013 at 3:55 PM, Eli Bendersky wrote:
>
>
>
> On Sun, May 5, 2013 at 3:34 PM, Tim Delaney
> wrote:
>>
>> On 6 May 2013 08:00, Guido van Rossum wrote:
>>>
>>> On Sun, May 5, 2013 at 2:55 PM, Tim Delaney
>>> wrote:
>>> > So long as I can get one of the requirements documented to im
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 5/5/2013 6:07 AM, Ethan Furman wrote:
class NEI( NamedInt, Enum ):
x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
@property
def __name__(self):
return self.value.__name__
This cured it, thank you. But I really still don't understand why the
numbers showed up as
On Sun, May 5, 2013 at 3:34 PM, Tim Delaney wrote:
> On 6 May 2013 08:00, Guido van Rossum wrote:
>
>> On Sun, May 5, 2013 at 2: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
On Sun, May 5, 2013 at 3:34 PM, Tim Delaney wrote:
> On 6 May 2013 08:00, Guido van Rossum wrote:
>>
>> On Sun, May 5, 2013 at 2: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 enum
On 6 May 2013 08:00, Guido van Rossum wrote:
> On Sun, May 5, 2013 at 2: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.
>
> Specifically what do you want the PEP to prom
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 05/05/2013 23:01, Matej Cepl wrote:
- Original Message -
From: "Armin Rigo"
To: "Matej Cepl"
Cc: python-dev@python.org
Sent: Saturday, May 4, 2013 11:59:42 AM
Subject: Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron Swartz
memorial)
Hi Matej,
On Thu, Mar 7, 2013 a
- Original Message -
> From: "Armin Rigo"
> To: "Matej Cepl"
> Cc: python-dev@python.org
> Sent: Saturday, May 4, 2013 11:59:42 AM
> Subject: Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron
> Swartz memorial)
>
> Hi Matej,
>
> On Thu, Mar 7, 2013 at 11:08 AM, Matej Cepl
On Sun, May 5, 2013 at 2: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.
Specifically what do you want the PEP to promise?
--
--Guido van Rossum (python.org/~guido)
_
On 6 May 2013 06:09, Ethan Furman wrote:
> On 05/05/2013 10:07 AM, � 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
>>
>
> No, you are not only one that's bothered by it. I tr
On 05/05/2013 10:07 AM, � 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
No, you are not only one that's bothered by it. I tried it without assignments until I discovered that bugs are way t
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
On 4 May 2013 16:42, Vinay Sajip wrote:
> I've taken a quick look at it, but I probably won't be able to make any
> changes until the near the end of the coming week. Feel free to have a go;
>
OK, I have a patch against the standalone pylauncher repo at
https://bitbucket.org/pmoore/pylauncher. I
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 05/05/2013 01:08 AM, Nick Coghlan wrote:
On Sun, May 5, 2013 at 5:21 PM, Ethan Furman wrote:
There's also the code in enum_type.__call__ that ensures Enum.__repr__
and Enum.__str__ are used in preference to those from the value type.
(Specifically, the code at
https://bitbucket.org/stoneleaf
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
class NEI( NamedInt, Enum ):
x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
@property
def __name__(self):
return self.value.__name__
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
On 5 May 2013 16:17, Ethan Furman wrote:
> On 05/04/2013 10:59 PM, Ethan Furman wrote:
>
>> On 05/04/2013 08:50 PM, Tim Delaney wrote:
>>
>>> 2. Instead of directly setting the _name and _value of the enum_item, it
>>> lets the Enum class do it via Enum.__init__().
>>>
>> Subclasses can override
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 Sun, May 5, 2013 at 5:21 PM, Ethan Furman wrote:
> When NamedInt goes looking for _name, it finds the one on `x`, not the one
> on `x.value`.
There's also the code in enum_type.__call__ that ensures Enum.__repr__
and Enum.__str__ are used in preference to those from the value type.
(Specifical
On 5/5/2013 12:21 AM, Ethan Furman wrote:
On 05/04/2013 11:31 PM, Glenn Linderman wrote:
x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
# demonstrate that NamedInt propagates the names into an expression
syntax
print( repr( x ), repr( y ), repr( x+y ))
from ref435 import Enum
# require
On 05/04/2013 11:31 PM, Glenn Linderman wrote:
x = NamedInt('the-x', 1 )
y = NamedInt('the-y', 2 )
# demonstrate that NamedInt propagates the names into an expression syntax
print( repr( x ), repr( y ), repr( x+y ))
from ref435 import Enum
# requires redundant names, but loses names in the exp
On 5/5/2013 12:10 AM, Glenn Linderman wrote:
On 5/4/2013 11:46 PM, Glenn Linderman wrote:
Somehow, the overloading is not finding the __add__ operator in the
NamedInt class, when the NamedInt's are wrapped in enumerations.
And I guess I figured it out... NamedInt needs to test
issubclass(
On 5/4/2013 11:46 PM, Glenn Linderman wrote:
Somehow, the overloading is not finding the __add__ operator in the
NamedInt class, when the NamedInt's are wrapped in enumerations.
And I guess I figured it out... NamedInt needs to test
issubclass( type( self ), NamedInt )
rather than
is
52 matches
Mail list logo
