[issue17963] Deprecate the frame hack for implicitly getting module details

Changes by Ethan Furman : -- nosy: -ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[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

[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 _

[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 w

[issue17963] Deprecate the frame hack for implicitly getting module details

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[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

[issue17963] Deprecate the frame hack for implicitly getting module details

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[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 wou

[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 ___ _

[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 ad

[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... o

[issue17963] Deprecate the frame hack for implicitly getting module details

Changes by Eli Bendersky : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue17963] Deprecate the frame hack for implicitly getting module details

Changes by Nick Coghlan : -- dependencies: +namedtuple should support fully qualified name for more portable pickling ___ Python tracker ___

[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__') exc