On Thu, 2 May 2013 13:15:00 -0700That's a fallacy. There is no step backwards if you adopt a class-based
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.
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".
It's not the notation which is hackish, it's the fact that you are
> If
> sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be
> shortened to a convenience function the stdlib provides?
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)?