[Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

[Eli Bendersky]

On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Thu, 2 May 2013 13:15:00 -0700
> Eli Bendersky <eliben at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130502/62e01933/attachment.html>