On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Thu, 2 May 2013 13:15:00 -0700
Eli Bendersky <eliben@gmail.com> wrote:
> > Two things that were suggested in private:
> >
> > 1) ask users to pass the module name to the convenience function
> > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the
> > class "name"). Guido doesn't like it :-)
> >
> > 2) dicth the "convenience function" and replace it with a regular
> > class-based syntax. Ethan doesn't like it :-)
> >
>
> Re (2), we already have the hack in stdlib in namedtuple, so not allowing
> it for an enum is a step backwards.

That's a fallacy. There is no step backwards if you adopt a class-based
syntax, which is just as convenient as the proposed "convenience
function". I have a hard time understanding that calling a function to
declare a class is suddenly considered "convenient".

> If
> sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be
> shortened to a convenience function the stdlib provides?

It's not the notation which is hackish, it's the fact that you are
inspecting the frame stack in the hope of getting the right information.

What if someone wants to write another convenience function that wraps
your convenience function? What if your code is executing from some
kind of step-by-step debugger which inserts an additional frame in the
call stack? What if someone wants the enum to be nested inside another
class (rather than reside at the module top-level)?

Would nesting the non-convenience Enum in a function or a class allow one to pickle it? I think programmers who want their libraries to be pickle-able already have to be aware of some restrictions about what can and cannot be pickled.

Eli