[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Glenn Linderman v+python at g.nevcal.com
Fri Apr 26 01:26:54 CEST 2013


On 4/25/2013 3:37 PM, Guido van Rossum wrote:
> On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsaw<barry at python.org>  wrote:
>> >On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
>>> >>I suppose you were going to propose to use isinstance() overloading,
>>> >>but I honestly think that Color.red.__class__ should be the same
>>> >>object as Color.
>> >
>> >Yes, a custom __instancecheck__() is two lines of code.
>> >
>> >I just can't get over the weirdness of a class having attributes which are
>> >actual instances of itself.
> TBH I had a hard time getting over the fact that even though the class
> said "a = 1", C.a is not the integer 1. But I did get over it.
> Hopefully you can get over*this*  weirdness.

:)

The minute "metaclass" is involved, it is no longer a class, but a 
whatchamacallit. What blows people's minds regarding metaclasses is that 
they aren't necessarily what they look like. In this case, we are 
defining enumerations using a syntax that sort of looks like class 
attribute syntax, which are neither classes, nor types, but rather a 
collection of cooperative objects with shared methods in a shared 
subsidiary namespace.

Perhaps instead of metaclass altering the behavior of classes, it might 
have been less confusing to simply define a new keyword 
"whatchamacallit" (or "metaclass") that have behaviors defined by the 
various methods defined in connection with it... while the existing 
techniques exist and would require a deprecation cycle to eliminate, it 
may not be too late to define alternate keywords that make it clearer 
that using such keywords, is making user-defined objects of some sort, 
class-like or -unlike, type-like or -unlike, object-like or -unlike, 
cooperative or not, etc., all by user definition. Any behavioral 
resemblance to classes would be only by user specification of same 
(perhaps such a specification of "same as class" should be easy).

My question is, once an enumeration is defined, is there a way, short of 
element-by-element assignment, to import the individual enumeration 
instances into the current namespace, so that I can say "red" instead of 
"Color.red" ? I understand the benefits of avoiding name collisions when 
there are lots of enumerations, and lots of opportunities for name 
collections between, say, RGBColor and CYMKColor... but there are lots 
of uses for enumerations where the subsidiary namespace is just 
aggravating noise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130425/43096a0e/attachment.html>


More information about the Python-Dev mailing list