[Python-Dev] PEP 435: pickling enums created with the functional API
ncoghlan at gmail.com
Thu May 9 16:17:18 CEST 2013
On 9 May 2013 13:48, "Eli Bendersky" <eliben at gmail.com> wrote:
> On Tue, May 7, 2013 at 8:03 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On Tue, May 7, 2013 at 11:34 PM, Eli Bendersky <eliben at gmail.com> wrote:
>> > One of the contended issues with PEP 435 on which Guido pronounced was
>> > functional API, that allows created enumerations dynamically in a
>> > similar to namedtuple:
>> > Color = Enum('Color', 'red blue green')
>> > The biggest complaint reported against this API is interaction with
>> > As promised, I want to discuss here how we're going to address this
>> > At this point, the pickle docs say that module-top-level classes can be
>> > pickled. This obviously works for the normal Enum classes, but is a
>> > with the functional API because the class is created dynamically and
>> > __module__.
>> > To solve this, the reference implementation is used the same approach
>> > namedtuple (*). In the metaclass's __new__ (this is an excerpt, the
>> > code has some safeguards):
>> > module_name = sys._getframe(1).f_globals['__name__']
>> > enum_class.__module__ = module_name
>> > According to an earlier discussion, this is works on CPython, PyPy and
>> > Jython, but not on IronPython. The alternative that works everywhere
>> > define the Enum like this:
>> > Color = Enum('the_module.Color', 'red blue green')
>> > The reference implementation supports this as well.
>> > Some points for discussion:
>> > 1) We can say that using the functional API when pickling can happen
>> > recommended, but maybe a better way would be to just explain the way
>> > are and let users decide?
>> It's probably worth creating a section in the pickle docs and
>> explaining the vagaries of naming things and the dependency on knowing
>> the module name. The issue comes up with defining classes in __main__
>> and when implementing pseudo-modules as well (see PEP 395).
>> > 2) namedtuple should also support the fully qualified name syntax. If
>> > is agreed upon, I can create an issue.
>> Yes, I think that part should be done.
As Eric noted on the tracker issue, a keyword only "module" argument may be
a better choice for both than allowing dotted names. A separate parameter
is easier to use with __name__ to avoid hardcoding the module name.
At the very least, the PEP should provide a rationale for the current
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev