On Thu, Feb 14, 2013 at 9:16 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

> You're still ignoring the less-magic solutions such as:
>
> class Errno(Enum):
>     __enumvalues__ = ('EBADF', 'ENOENT',)

Yes, an approach like that, or anything similarly explicit would be
fine with me (and has the virtue of potentially supporting pickle,
unlike anonymous class generators like the current namedtuple
implementation). It was the clever insanity of some of the other ideas
being kicked around in these threads that I wanted to be clear I would
fight tooth and nail if they were ever actually proposed for stdlib
inclusion.

My enthusiasm for flufl.enum in particular is mainly of the "I'm tired
of seeing almost the exact same enum discussion get rehashed every
couple of years, and that one looks good enough to me" variety, so it
probably isn't wise to pay too much attention to me when it comes to
the specific of the API :P

Your comments did give me an idea about namedtuple though - I'll start
another thread about that.

> I find it slightly amusing that you're complaining about a violation
> one of your latest PEPs is trying to make easier to make.

[Replying to this second, since it is getting into philosophy of
language design, and I actually agree with your key point above]

I have a long history of trying to demystify various aspects of Python
metaprogramming and make it easier for people to explore the language,
and create suitable meta-frameworks for their own use, and for use
within particular subcommunities.

As I see it, violating normal expectations for class behaviour *within
the context of a framework* is fine, *so long as you can't achieve
reasonable syntax in a simpler way*. Environments like Django, SQL
Alchemy, etc set up new norms about expected behaviour in different
kinds of classes, and that's the entire reason I think these
metaprograming tools are worth providing in the first place (although
I acknowledge it *can* cause problems when people learn one of these
frameworks *first*, and then later need to be taught the difference
between the automatically provided framework level behaviour for
Forms, Models, Views, etc and the underlying standard language
behaviour).

While the standard library already provides three distinct class level
behaviours (normal classes, subclasses of type and ABCs), those are
each intertwined deeply with the core type system (arguably,
inheriting from builtins other than type or object counts as an
additional case, since inheriting from a C defined class that isn't
really designed for it has interesting consequences in CPython due to
implementation limitations). Furthermore, while our variants change
the way instantiation, descriptors, isinstance and issubclass behave
after the class is created, they *don't* alter the runtime semantics
of the class body itself.

To my mind, defining enumerations doesn't even come close to reaching
the bar that would justify highly customised class behaviour that a
reader can't guess simply from knowing Python and reading the code (I
get the impression you already agree with me on this point, which is
why I moved this philosophical section after my agreement with you
above).

Cheers,
Nick

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas