[docs] [issue17947] Code, test, and doc review for PEP-0435 Enum

Nick Coghlan report at bugs.python.org
Sun May 12 08:25:55 CEST 2013

Nick Coghlan added the comment:

Guido has promised an explanation for why he wants to keep the frame hack once he is back at work next week. To help him target that reply appropriately for my concrete objections to retaining it, I'd like to explain a bit more about why I think it's fundamentally impossible to create a robust stack inspection mechanism for implicit pickling support. Even if a dedicated mechanism for it is added, the information the interpreter needs to make a sensible reliable decision simply isn't there.

Consider the following:

    # In utils.py
    def enum_helper(name, prefix, fields):
        if isinstance(fields, str): fields = fields.split()
        e = Enum(name, (prefix + field for field in fields))
        return e

    # In some other module
    from utils import enum_helper
    MyEnum = enum_helper(MyEnum, "st_", "mtime atime ctime")

This breaks the frame hack, but would work correctly if enum_helper was redesigned to accept an explicit module name, or if we adopted something like the "name binding protocol" discussed on Python ideas.

If we adopted a simplistic rule of ignoring function scopes and only look at module and class scopes, then we break the semantics of the global keyword.

I consider the frame hack fundamentally broken, since there's currently no way the interpreter can distinguish between an incidental assignment (like the "e = Enum..." call in util.py) and a destination assignment (like the "MyEnum = enum_helper..." call), and if we *do* add a different syntax for "this supports pickling" assignments (like the def name = expr syntax on Python ideas), then a name binding protocol makes more sense than implicit contextual magic.


Python tracker <report at bugs.python.org>

More information about the docs mailing list