[Python-Dev] PEP-435 reference implementation

[Ethan Furman]

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~