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 that the instance/class/subclass relationships
> make any sense.
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 trump hypothetical purity.
I have real-world use cases of enums (in java) that are essentially classes and
happen to use the enum portion purely to
obtain a unique name without explicitly supplying an ID.
In the particular use case I'm thinking of, the flow is basically like this:
1. An Enum where each instance describes the shape of a database query.
2. Wire protocol where the Enum instance name is passed.
3. At one end, the data for performing the DB query is populated.
4. At the other end, the data is extracted and the appropriate enum is used to
perform the query.
Why use an enum? By using the name in the wire protocol I'm guaranteed a unique
ID that won't change across versions
(there is a requirement to only add to the enum) but does not rely on people
setting it manually - the compiler will
complain if there is a conflict, as opposed to setting values. And having the
behaviour be part of the class simplifies
things immensely.
Yes, I could do all of this without an enum (have class check that each
supplied ID is unique, etc) but the code is much
clearer using the enum.
I am happy to give up subclassing of enums in order to have behaviour on enum
instances. I've always seen enums more as
a container for their instances. I do want to be able to find out what enum
class a particular enum belongs to (I've
used this property in the past) and it's nice that the enum instance is an
instance of the defining class (although IMO
not required).
I see advantages to enums being subclassable, but also significant
disadvantages. For example, given the following:
class Color(Enum):
red = 1
class MoreColor(Color):
blue = 2
class DifferentMoreColor(Color):
green = 2
then the only reasonable way for it to work IMO is that MoreColor contains both
(red, blue) and DifferentMoreColor
contains both (red, green) and that red is not an instance of either MoreColor
or DifferentMoreColor. If you allow
subclassing, at some point either something is going to be intuitively
backwards to some people (in the above that
Color.red is not an instance of MoreColor), or is going to result in a
contravariance violation.
Nice example, thank you.
As far as subclassing goes, you can have behavior either way. The sticky issue is are the enum items from an inherited
enumeration available in the child enumeration, or should such an inheritance raise an error, or should all subclassing
inheritance raise an error.
It sounds like we're leaning towards allowing subclassing as long as the enumeration being subclassed doesn't define any
enum items itself.
--
~Ethan~
_______________________________________________
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
