[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)
Barry Warsaw barry at python.org
Fri Apr 26 00:23:10 CEST 2013
- Previous message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Next message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Apr 22, 2013, at 10:42 AM, Nick Coghlan wrote:
On Mon, Apr 22, 2013 at 10:28 AM, Barry Warsaw <barry at 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?
My point is, "days of the week" has a natural ordering, so why wouldn't you use IntEnum for that? Problem solved.
There's no natural ordering for things like colors or animals, so the values don't matter. I claim that neither does the repr or iteration order except that the former should be predictable and it would be nice to define the latter, but that's not actually necessary. Undefined iteration order would be just as fine for Enum.
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.
I don't see how iteration order could affect how you'd write the derived class syntax.
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).
Maybe. If they care about iteration order at all, then they will have to special case their code for Python's < 3.3, which means they'll probably have to explicitly sort it anyway for the foreseeable future. I guess it'll be moot in 10 years though. ;)
They probably don't care about iteration order, which I think will be the common case (heck, iteration over the enum will be pretty rare anyway).
-Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20130425/e06cc822/attachment.pgp>
- Previous message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Next message: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]