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 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 05/04/2013 08:50 PM, Tim Delaney wrote:
Think I've come up with a system that works for my auto-numbering case without
knowing the internals of enum_type. Patch
passes all existing test cases. The patch does two things:
1. Finds the first non-Enum class on the MRO of the new class and uses
On 05/04/2013 10:59 PM, Ethan Furman wrote:
On 05/04/2013 08:50 PM, Tim Delaney wrote:
Think I've come up with a system that works for my auto-numbering case without
knowing the internals of enum_type. Patch
passes all existing test cases. The patch does two things:
[snip]
2. Instead of d
Split off from the PEP 435 - requesting pronouncement thread.
Think I've come up with a system that works for my auto-numbering case
without knowing the internals of enum_type. Patch passes all existing test
cases. The patch does two things:
1. Finds the first non-Enum class on the MRO of the new
On Thu, May 2, 2013 at 11:37 AM, Steven D'Aprano wrote:
> On 02/05/13 08:54, Nick Coghlan wrote:
>
>> If enums had an "as_dict" method that returned an ordered dictionary, you
>> could do:
>>
>> class MoreColors(Enum):
>> locals().update(Colors.as_dict())
>
>
>
> Surely that is an implementat
On 02/05/13 02:43, Guido van Rossum wrote:
Here's how I would implement "extending" an enum if subclassing were
not allowed:
class Color(Enum):
red = 1
white = 2
blue = 3
class ExtraColor(Enum):
orange = 4
yellow = 5
green = 6
flag_colors = set(Color) | set(ExtraColor)
Now
On 02/05/13 08:54, Nick Coghlan wrote:
If enums had an "as_dict" method that returned an ordered dictionary, you
could do:
class MoreColors(Enum):
locals().update(Colors.as_dict())
Surely that is an implementation-specific piece of code? Writing to locals()
is not guaranteed to work, an
On 2 May 2013 02:46, "Guido van Rossum" wrote:
>
> On Wed, May 1, 2013 at 9:18 AM, Tres Seaver wrote:
> > I'd be glad to drop both of those in favor of subclassing: I think the
> > emphasis on "class-ness" makes no sense, given the driving usecases for
> > adopting enums into the stdlib in the f
On 05/01/2013 02:36 PM, Tim Delaney wrote:
On 2 May 2013 02:18, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/01/2013 12:14 PM, Guido van Rossum wrote:
> But we'd probably have to give up something else, e.g. adding methods
> to enums, or any hope th
On 2 May 2013 02:18, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/01/2013 12:14 PM, Guido van Rossum wrote:
> > But we'd probably have to give up something else, e.g. adding methods
> > to enums, or any hope that the instance/class/subclass relationships
> > make
On Wed, May 1, 2013 at 9:18 AM, Tres Seaver wrote:
> I'd be glad to drop both of those in favor of subclassing: I think the
> emphasis on "class-ness" makes no sense, given the driving usecases for
> adopting enums into the stdlib in the first place. IOW, I would vote
> that real-world usecases
Am 01.05.2013 17:09, schrieb Ethan Furman:
> New repo to avoid confusion:
>
> https://bitbucket.org/stoneleaf/ref435
>
> which has the latest updates from the feedback.
>
> Subclassing is again disabled. Let's get the rest of it done, then we can
> come back to that issue if necessary.
Thanks.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/01/2013 12:14 PM, Guido van Rossum wrote:
> But we'd probably have to give up something else, e.g. adding methods
> to enums, or any hope that the instance/class/subclass relationships
> make any sense.
I'd be glad to drop both of those in favor
Am 01.05.2013 17:35, schrieb Steven D'Aprano:
> On 02/05/13 01:09, Ethan Furman wrote:
>> New repo to avoid confusion:
>>
>> https://bitbucket.org/stoneleaf/ref435
>
> Apparently I have to log in before I can even see the repo.
>
> Not going to happen.
I'm sure he made the repo private by accide
Personally I would probably compare enums using ==, but I agree that
'is' should also work -- since the instances are predefined there's no
reason to ever have multiple equivalent instances, so we might as well
guarantee it.
I'm sorry that my requirements for the relationship between the enum
clas
On Apr 30, 2013, at 10:50 PM, Ethan Furman wrote:
>The way I had subclassing working originally was for the subclass to create
>it's own versions of the superclass' enum items -- they weren't the same
>object, but they were equal:
>
>--> class Color(Enum):
>... red = 1
>... green = 2
>...
On 05/01/2013 08:35 AM, Steven D'Aprano wrote:
On 02/05/13 01:09, Ethan Furman wrote:
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
Apparently I have to log in before I can even see the repo.
Not going to happen.
Sorry, just made it public. Try again?
--
~Ethan~
___
I can see it just fine without logging in, even in an Incognito Chrome window.
On Wed, May 1, 2013 at 8:35 AM, Steven D'Aprano wrote:
> On 02/05/13 01:09, Ethan Furman wrote:
>>
>> New repo to avoid confusion:
>>
>> https://bitbucket.org/stoneleaf/ref435
>
>
> Apparently I have to log in before I
On 02/05/13 01:09, Ethan Furman wrote:
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
Apparently I have to log in before I can even see the repo.
Not going to happen.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.or
New repo to avoid confusion:
https://bitbucket.org/stoneleaf/ref435
which has the latest updates from the feedback.
Subclassing is again disabled. Let's get the rest of it done, then we can come
back to that issue if necessary.
--
~Ethan~
___
Pytho
On 05/01/2013 12:05 AM, Steven D'Aprano wrote:
On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote:
Latest code available at https://bitbucket.org/stoneleaf/aenum.
Ethan, you seem to be writing a completely new PEP in opposition to
Barry's PEP 435. But your implementation doesn't seem
On 4/30/2013 9:19 PM, Ethan Furman wrote:
Latest code available at https://bitbucket.org/stoneleaf/aenum.
--> class Color(Enum):
... red = 1
... green = 2
... blue = 3
Enum items are virtual attributes looked by EnumType's __getattr__.
The win here is that
--> Color.red.green.bl
On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote:
> Latest code available at https://bitbucket.org/stoneleaf/aenum.
>
> --> class Color(Enum):
> ... red = 1
> ... green = 2
> ... blue = 3
Ethan, you seem to be writing a completely new PEP in opposition to
Barry's PEP 435.
On 04/30/2013 10:41 PM, Barry Warsaw wrote:
What does it break if you remove the `if base._enum` check? I mean, can we be
consenting adults here or not?
I removed the error and added a couple lines to EnumType.__getattr_, and now subclassing works as I think you are used
to it working.
Ver
On 04/30/2013 09:47 PM, Barry Warsaw wrote:
On Apr 30, 2013, at 07:39 PM, Glenn Linderman wrote:
Because Guido said no subclassing.
Indeed, I heard him. But what I heard was that subclasses shouldn't be
allowed to define new enumeration values, and that was the point of all his
justification
On Apr 30, 2013, at 09:19 PM, Ethan Furman wrote:
>Subclassing an implemented Enum class now raises an error (is there a better
>word than 'implemented'?)
>
>--> class MoreColor(Color):
>... cyan = 4
>... magenta = 5
>... yellow = 6
>
>Traceback (most recent call last):
> File "", li
On Apr 30, 2013, at 07:39 PM, Glenn Linderman wrote:
>>> Because Guido said no subclassing.
>
>Indeed, I heard him. But what I heard was that subclasses shouldn't be
>allowed to define new enumeration values, and that was the point of all his
>justification and the justifications in the Stack Ove
Latest code available at https://bitbucket.org/stoneleaf/aenum.
--> class Color(Enum):
... red = 1
... green = 2
... blue = 3
Enum items are virtual attributes looked by EnumType's __getattr__. The win
here is that
--> Color.red.green.blue
no longer works. ;)
Subclassing an imp
On 4/30/2013 4:49 PM, Ethan Furman wrote:
On 04/30/2013 03:34 PM, Ethan Furman wrote:
On 04/30/2013 03:24 PM, Glenn Linderman wrote:
On 4/30/2013 1:12 PM, Ethan Furman wrote:
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org
On 04/30/2013 03:34 PM, Ethan Furman wrote:
On 04/30/2013 03:24 PM, Glenn Linderman wrote:
On 4/30/2013 1:12 PM, Ethan Furman wrote:
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref
On 04/30/2013 03:24 PM, Glenn Linderman wrote:
On 4/30/2013 1:12 PM, Ethan Furman wrote:
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref435.py
Thanks for the code reference.
Test
On 4/30/2013 1:12 PM, Ethan Furman wrote:
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py
and test_ref435.py
Thanks for the code reference.
Tests ran fine here on Python 3.3
If I alter test_r
On 04/30/2013 01:12 PM, Ethan Furman wrote:
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref435.py
Oh, as written in requires 3.3+. If you want to play around with it and are stuck on an earlier version, remove the
`from None` on line 68.
--
~Ethan~
_
On Tue, Apr 30, 2013 at 1:12 PM, Ethan Furman wrote:
> Greetings,
>
> Eli asked me to put the reference implementation here for review.
>
> It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
> test_ref435.py
>
Thanks, Ethan.
All - note that strictly speaking this impleme
Greetings,
Eli asked me to put the reference implementation here for review.
It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and
test_ref435.py
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
36 matches
Mail list logo
