[Python-Dev] PEP-435 reference implementation (original) (raw)
Tim Delaney timothy.c.delaney at gmail.com
Wed May 1 23:36:08 CEST 2013
- Previous message: [Python-Dev] PEP-435 reference implementation
- Next message: [Python-Dev] PEP-435 reference implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2 May 2013 02:18, Tres Seaver <tseaver at palladion.com> 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:
- An Enum where each instance describes the shape of a database query.
- Wire protocol where the Enum instance name is passed.
- At one end, the data for performing the DB query is populated.
- 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.
Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130502/c371d617/attachment.html>
- Previous message: [Python-Dev] PEP-435 reference implementation
- Next message: [Python-Dev] PEP-435 reference implementation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]