Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Barry Warsaw wrote: On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote: class Insect(Enum): wasp = wsap = 1 bee = 2 ant = 3 What's the justification for this restriction? I have looked in the PEP, and didn't see one. If you allowed this, there would be no way to look up an enumeration item by value. This is necessary for e.g. storing the value in a database. Hm. What you really want there isn't two enum objects with the same value, but two names bound to the same enum object. Then looking it up by value would not be a problem. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 21 April 2013 21:02, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Barry Warsaw wrote: On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote: class Insect(Enum): wasp = wsap = 1 bee = 2 ant = 3 What's the justification for this restriction? I have looked in the PEP, and didn't see one. If you allowed this, there would be no way to look up an enumeration item by value. This is necessary for e.g. storing the value in a database. Hm. What you really want there isn't two enum objects with the same value, but two names bound to the same enum object. Then looking it up by value would not be a problem. If there were some way to identify the canonical name a lookup by value would be unambiguous. If we have iteration in definition order, I'd say the first defined name for a value should be the canonical name, and any other name for the value should be considered an alias. That would preclude the syntax above, but the following might be workable: class Insect(Enum): wasp = 1 bee = 2 ant = 3 # aliases wsap = wasp waps = 1 In the above, looking up by the value 1 would always return Insect.wasp. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 21/04/13 15:33, Nick Coghlan wrote: The PEP is fine, as it already allows duplicate names without encouraging them: class Insect(Enum): wasp = 1 # Preferred. Use this in new code. bee = 2 ant = 3 # Backwards compatibility aliases Insect.wsap = Insect.wasp Hmmm, I must have missed this. That satisfies my use-cases. Objection withdrawn. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Apr 20, 2013, at 07:10 PM, R. David Murray wrote: It seems strange to limit a new Python3 feature to the Python2 feature set. Just saying :) For a critical feature sure, but I don't put __repr__ or enum item iteration order in that category. There's no need for gratuitous incompatibility either, and attribute name order is just fine. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Fine with me. On Sun, Apr 21, 2013 at 2:47 PM, Barry Warsaw ba...@python.org wrote: On Apr 20, 2013, at 07:10 PM, R. David Murray wrote: It seems strange to limit a new Python3 feature to the Python2 feature set. Just saying :) For a critical feature sure, but I don't put __repr__ or enum item iteration order in that category. There's no need for gratuitous incompatibility either, and attribute name order is just fine. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Apr 21, 2013, at 03:25 PM, Nick Coghlan wrote: Agreed. I think the stdlib enum library should use __prepare__ and iterate in definition order (since 2.x compatibility isn't of any concern), while flufl.enum can use sorted by name as the iteration order. An order_by_name keyword argument to __prepare__ in the stdlib version could then allow the user to opt in to the flufl.enum behaviour, while still using definition order by default. Seriously, why all the extra complexity for something you'll never care about? You don't care about the exact contents of __repr__ as long as it's predictable. You don't really care about item iteration order either as long as it's defined. Sorting by attribute name fulfills both use cases *and* it's simple. Zen 3 FTW. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Apr 22, 2013, at 12:06 AM, Steven D'Aprano wrote: On 21/04/13 15:33, Nick Coghlan wrote: The PEP is fine, as it already allows duplicate names without encouraging them: class Insect(Enum): wasp = 1 # Preferred. Use this in new code. bee = 2 ant = 3 # Backwards compatibility aliases Insect.wsap = Insect.wasp Hmmm, I must have missed this. That satisfies my use-cases. Objection withdrawn. Yay! -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 22 Apr 2013 07:50, Barry Warsaw ba...@python.org wrote: On Apr 20, 2013, at 07:10 PM, R. David Murray wrote: It seems strange to limit a new Python3 feature to the Python2 feature set. Just saying :) For a critical feature sure, but I don't put __repr__ or enum item iteration order in that category. There's no need for gratuitous incompatibility either, and attribute name order is just fine. Iteration order matters a lot if you don't want people complaining about enums being broken: class Days(enum.Enum): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 Cheers, Nick. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 22 April 2013 09:02, Nick Coghlan ncogh...@gmail.com wrote: On 22 Apr 2013 07:50, Barry Warsaw ba...@python.org wrote: On Apr 20, 2013, at 07:10 PM, R. David Murray wrote: It seems strange to limit a new Python3 feature to the Python2 feature set. Just saying :) For a critical feature sure, but I don't put __repr__ or enum item iteration order in that category. There's no need for gratuitous incompatibility either, and attribute name order is just fine. Iteration order matters a lot if you don't want people complaining about enums being broken: class Days(enum.Enum): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 I'm fine with iteration order being by sorted name by default, so long as it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum should probably iterate in value order. For definition order, a 3.x-only metaclass could be provided: class Days(enum.Enum, metaclass=enum.DefinitionOrder): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote: Iteration order matters a lot if you don't want people complaining about enums being broken: class Days(enum.Enum): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 Sorry, that's still not a complete use case. I don't see why you'd depend on iteration order over Days for any particular functionality. Besides, if you did, I think it would be better to derive Days from IntEnum and then iteration order is guaranteed over the values. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote:
I'm fine with iteration order being by sorted name by default, so long as
it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
should probably iterate in value order.
It does/timemachine. :)
For definition order, a 3.x-only metaclass could be provided:
class Days(enum.Enum, metaclass=enum.DefinitionOrder):
Monday = 1
Tuesday = 2
Wednesday = 3
Thursday = 4
Friday = 5
Saturday = 6
Sunday = 7
Yep, that's how it works. From flufl.enum:
class IntEnumMetaclass(EnumMetaclass):
# Define an iteration over the integer values instead of the attribute
# names.
def __iter__(cls):
for key in sorted(cls._enums):
yield getattr(cls, cls._enums[key])
IntEnum = IntEnumMetaclass(str('IntEnum'), (Enum,), {
'__doc__': 'A specialized enumeration with values that are also integers.',
'__value_factory__': IntEnumValue,
})
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw ba...@python.org wrote: On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote: Iteration order matters a lot if you don't want people complaining about enums being broken: class Days(enum.Enum): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 Sorry, that's still not a complete use case. I don't see why you'd depend on iteration order over Days for any particular functionality. You mean other than printing the days of the week in order without needing to worry about the specific values assigned to them? Using sort-by-name also introduces other weirdness, such as subclasses potentially inserting their values in the middle of inherited names, rather than appending to the end as one might reasonably expect. While using sort-by-name is better than not providing a consistent ordering at all, using definition order is substantially less surprising than sorting by key name, and PEP 3115 and collections.OrderedDict makes that easy to support in Python 3.x. The fact that this will make for a behavioural difference between the standard library and flufl.enum does *not* count as an argument for making the behaviour of the standard library version less intuitive (if that was a valid argument, the 3.3+ ipaddress module would look a *lot* more like it's ipaddr inspiration). Besides, if you did, I think it would be better to derive Days from IntEnum and then iteration order is guaranteed over the values. But only at the cost of breaking the other guarantees provided by a standard enumeration. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On 22 April 2013 10:31, Barry Warsaw ba...@python.org wrote: On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote: I'm fine with iteration order being by sorted name by default, so long as it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum should probably iterate in value order. It does/timemachine. :) I knew it *did*, but wasn't sure if with the current discussion it was going to continue to do so. For definition order, a 3.x-only metaclass could be provided: class Days(enum.Enum, metaclass=enum.DefinitionOrder): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 Yep, that's how it works. From flufl.enum: class IntEnumMetaclass(EnumMetaclass): # Define an iteration over the integer values instead of the attribute # names. def __iter__(cls): for key in sorted(cls._enums): yield getattr(cls, cls._enums[key]) Would it be worthwhile storing a sorted version of the enum keys here? Or do you think the current space vs speed tradeoff is better? I need to grab the current flufl.enum code and see if I can easily extend it to do some more esoteric things that my enum implementation supports (*not* bare names, but maybe the name = ... syntax, which of course requires the definition order metaclass). I'm in the middle of a release cycle, so my time is somewhat limited right now :( Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Sun, 21 Apr 2013 20:28:16 -0400, Barry Warsaw ba...@python.org wrote: On Apr 22, 2013, at 09:02 AM, Nick Coghlan wrote: Iteration order matters a lot if you don't want people complaining about enums being broken: class Days(enum.Enum): Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6 Sunday = 7 Sorry, that's still not a complete use case. I don't see why you'd depend on iteration order over Days for any particular functionality. Besides, if you did, I think it would be better to derive Days from IntEnum and then iteration order is guaranteed over the values. I didn't read Nick's message as being about a use case. The key word in the sentence above was complaining :) Regardless of the specific values involved, it is pretty much guaranteed that if anything other than definition order is used we *will* get bug reports/enhancement requests to fix it, on a regular basis. We can choose to live with that, but we should admit that it will will happen :) --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Sun, Apr 21, 2013 at 5:55 PM, Tim Delaney timothy.c.dela...@gmail.com wrote: On 22 April 2013 10:31, Barry Warsaw ba...@python.org wrote: On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote: I'm fine with iteration order being by sorted name by default, so long as it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum should probably iterate in value order. It does/timemachine. :) I knew it *did*, but wasn't sure if with the current discussion it was going to continue to do so. In any case I think it would be odd if IntEnum used a different policy than Enum. That would be a disturbing difference in behavior between two otherwise rather similar classes. Regardless of the specific values involved, it is pretty much guaranteed that if anything other than definition order is used we *will* get bug reports/enhancement requests to fix it, on a regular basis. We can choose to live with that, but we should admit that it will will happen :) I'm convinced. I also think that 2/3 compatibility is not as important as getting it right for the foreseeable future. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
