<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#330033" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 4/25/2013 3:37 PM, Guido van Rossum
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAP7+vJ+8HR=BX=w6o8Nb4kNKFefPQSc6L7goN7LHsCP_w=2YRA@mail.gmail.com"
      type="cite">
      <pre wrap="">On Thu, Apr 25, 2013 at 3:29 PM, Barry Warsaw <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:barry@python.org"><barry@python.org></a> wrote:
</pre>
      <blockquote type="cite" style="color: #000000;">
        <pre wrap=""><span class="moz-txt-citetags">> </span>On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
</pre>
        <blockquote type="cite" style="color: #000000;">
          <pre wrap=""><span class="moz-txt-citetags">>></span>I suppose you were going to propose to use isinstance() overloading,
<span class="moz-txt-citetags">>></span>but I honestly think that Color.red.__class__ should be the same
<span class="moz-txt-citetags">>></span>object as Color.
</pre>
        </blockquote>
        <pre wrap=""><span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>Yes, a custom __instancecheck__() is two lines of code.
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>I just can't get over the weirdness of a class having attributes which are
<span class="moz-txt-citetags">> </span>actual instances of itself.
</pre>
      </blockquote>
      <pre wrap="">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 <b class="moz-txt-star"><span class="moz-txt-tag">*</span>this<span class="moz-txt-tag">*</span></b> weirdness.</pre>
    </blockquote>
    <br>
    :)<br>
    <br>
    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.<br>
    <br>
    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).<br>
    <br>
    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.<br>
  </body>
</html>