New submission from Nick Coghlan:
(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.
----------
assignee: gvanrossum
messages: 189028
nosy: eli.bendersky, gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: Deprecate the frame hack for implicitly getting module details
type: enhancement
versions: Python 3.4
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17963>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
