[issue17963] Deprecate the frame hack for implicitly getting module details
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: -ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17963 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17963] Deprecate the frame hack for implicitly getting module details
Eli Bendersky added the comment: I don't have time, unfortunately. So other folks can pick this up. I don't remember if I made any progress on this - will post whatever I have if I find something. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17963 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17963] Deprecate the frame hack for implicitly getting module details
Ethan Furman added the comment: Eli, did you ever make any progress with this? Anything you can post so someone else can run with it if you don't have time? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17963 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17963] Deprecate the frame hack for implicitly getting module details
Eli Bendersky added the comment: I'm (somewhat) back looking at this. Should the first step be sys.get_calling_module_name()? I can provide a patch. Re its name, perhaps the long name isn't that bad given that this is a rather obscure API. But suggestions for something shorter/better will be welcome. -- ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Guido van Rossum added the comment: As I explained in issue 17947, I think that any Python implementation worth its salt should be able to implement sys.get_calling_module_name() (*), at least for the case where the caller is top-level code in a module body. That is a much weaker requirement than being able to implement sys._getframe(). We should just add this to CPython 3.4 and require that conforming implementations support it, at least in the stated context (top-level caller). (*) Please pick a somewhat shorter name for it. -- assignee: gvanrossum - ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
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
[issue17963] Deprecate the frame hack for implicitly getting module details
Changes by Nick Coghlan ncogh...@gmail.com: -- dependencies: +namedtuple should support fully qualified name for more portable pickling ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Changes by Eli Bendersky eli...@gmail.com: -- nosy: +rhettinger ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Ethan Furman added the comment: I believe Guido will be happy to replace the frame hack once we have something better, such as a way to implicitly (or explicitly in the case of helper functions) pass the calling module's name. Maybe a global __calling_module__ that a function can look at... or something similar, anyway. -- nosy: +ethan.furman ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Nick Coghlan added the comment: Right, but I think it's categorically impossible to make that work reliably without new syntax and a name binding protocol (or something equivalent). Due to the existence of the global keyword, the frame stack and normal assignment syntax simply don't provide adequate information for us to tell the difference between incidental assignments in a helper function and definite assignments that represent the ultimate destination. And if the solution involves new syntax, then the frame hack will have to be deprecated at some point anyway. -- ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Nick Coghlan added the comment: Oops, that was supposed to be definitive assignments in my previous comment. -- ___ 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
[issue17963] Deprecate the frame hack for implicitly getting module details
Brett Cannon added the comment: If you read the docs for sys._getframe() (http://docs.python.org/3/library/sys.html#sys._getframe) we explicitly state that the function should be considered an implementation detail for CPython. While Nick doesn't want to argue from the VM angle, I will. I would prefer to not rely on this hack in the stdlib to not put the other VMs at a disadvantage. Nick also has a good point that it is at best a heuristic as you can fool it into using the wrong result. At minimum I think the keyword argument for the module being used should be provided and documented that if it isn't provided then pickling is wishy-washy based on how you call the function and that it is not cross-VM compatible. But knowing that users won't clearly read the docs if it just happens to work in the interpreter and that is partial luck because of the possible indirection issue Nick pointed out, I think it would be better to not rely upon sys._getframe() and just ask people to explicitly specify the module if they happen to care about pickling *and* are using the functional API for enums. -- nosy: +brett.cannon ___ 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
