Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Wait... so enums are not integers, yet it's difficult not to give them each a number!? I must have missed something.
An "enum" for Python 3
Posted May 23, 2013 5:14 UTC (Thu) by gdt (guest, #6284)
As a everyday example of this, counting numbers (1, 2, 3, ...) are incomplete for the subtraction operator. Try to represent 1 - 2 as a counting number.
Some of the questions in the mailing list were around what arithmetic properties a enum has: for example, are they ordered (ie, red < green). Since maths doesn't care for enums much (and so doesn't define them with rigor), the real question was what properties should a enum have to be useful for programming. For example, it was widely felt that (red + green) should not evaluate as it indicates a programming error.
Enums might be implemented using integers. But one can say the same for sets. The whole point of a programming language is to develop useful abstractions to simplify the programming task, otherwise it may as well be assembler.
Posted May 23, 2013 7:31 UTC (Thu) by micka (subscriber, #38720)
Posted May 23, 2013 8:16 UTC (Thu) by jezuch (subscriber, #52988)
My thought as well. At this point it looks like it's a calque of enums from C (i would say "mindless" but it *was* discussed to death, after all ;) ). Having lived with enums in Java (which I find, frankly, rather excellent), I think it's a huge lost opportunity.
Posted May 23, 2013 16:06 UTC (Thu) by pboddie (guest, #50784)
The problem with introducing something similar in Python and having it as elegant as one might wish for is the unfortunate aversion amongst the core developers to changing the language syntax, even if that is really the best or most logical path to take in order to be able to express the new feature. So we end up with the risk that there is a shoe-horning of features into existing constructs that will probably serve to unnecessarily confuse people in future.
I suppose that one might look at the way it has been done and to consider more general mechanisms. In effect, values in PEP 435 enumerations can be regarded as predefined instances of the enumeration class, which I think is not always logical, since a colour is not an instance of a set of colours but rather a member of that set, although such a distinction is not always informative (integers are instances of the int type which can more or less be considered as the set of all integers even though it isn't really such a thing). However, this does allow us to consider using a similar shorthand elsewhere to define restricted collections of instances for a class.
What was noted in Andrew Cooke's response to the PEP is that the issue of introducing atoms/symbols in Python has been avoided once again. This would have been a particularly appropriate occasion to consider that matter.
Posted May 23, 2013 8:33 UTC (Thu) by nix (subscriber, #2304)
Posted May 24, 2013 7:49 UTC (Fri) by jezuch (subscriber, #52988)
Or you could allow enums to have members - fields and methods - and provide the conversion yourself when needed. You could also add some syntactic sugar for the common case. That's one of the great things about enums in Java - they are almost-regular classes, so they can engage in (interface) inheritance and polymorphism at will. Oh, and you can switch() on them ;)
Posted May 23, 2013 8:34 UTC (Thu) by nix (subscriber, #2304)
Posted May 23, 2013 8:58 UTC (Thu) by micka (subscriber, #38720)
Posted May 23, 2013 9:37 UTC (Thu) by nix (subscriber, #2304)
Posted May 23, 2013 10:31 UTC (Thu) by ballombe (subscriber, #9523)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds