(Split off from issue 17947)

collections.namedtuple includes a frame hack that attempts to make the functional API work for ordinary module level assignments:

    try:
        result.__module__ = _sys._getframe(1).f_globals.get('__name__', '__main__')
    except (AttributeError, ValueError):
        pass


I *really* don't like the fact that this hack is being incorporated into the PEP 435 implementation as well, when that API has been designed to include an explicit cross-implementation workaround for this case.

Eli asked me to move the discussion over to a new issue to allow the implementation issue to focus on incorporating the PEP as is.

Issue 17941 (the explicit module keyword-only argument) suggest incorporating PEP 435's robust, cross-implementation way to support pickling in the functional API into collection namedtuple as well, suggesting to me that the frame hack should be deprecated, not propagated further.

The main reason I don't like it is not the fact it doesn't work reliably on other implementations, but the fact it doesn't work reliably in CPython either - if you create a helper function, then the frame hack will pick up the module where the helper function lives rather than where you ultimately store the created object. Without some explicit way of telling the created object the final destination (whether through an argument or through new syntax and a name binding protocol), I don't see a way to resolve this dilemna in a robust way.

However, Guido tells me that he really wants to keep the frame hack (and include it for PEP 435 as well), so this issue is basically about documenting that rationale somewhere.