On 4/25/2013 3:37 PM, Guido van Rossum wrote:
On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsaw<ba...@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.
_______________________________________________
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
