Terry J. Reedy <tjre...@udel.edu> added the comment:
Given the absence of agreement among core-devs, a PR is a bit premature. Looking again at the existing docstring, I think it must be revised before copying and *not* copied as is. 0. The existing first sentence mislead me. The 'source or compiled file' must be a Python source or compiled Python (.pyc) file. An object in a compiled C file gives a TypeError. Change 'an object' to 'a Python-coded object'. 1. The 'object' argument cannot be just any Python-coded object (class object instance). Based on the exception message, add this second sentence: "The object must be a module, class, method, function, traceback, frame, or code object." Otherwise, TypeError. 2. The second paragraph is garbled. All objects in a module have a common origin, not a unique origin. I think the idea is that the name for the origin should be a standardized full path. I think that this paragraph adds so little that it should be deleted rather than revised. What paused this issue was Brett's opinion that getabsfile is untrustworthy and, with __file__ absolute, 'pointless', to a degree that it should not be documented. (If that were true, it should be deprecated.) I read the 3.7.2 source for getabsfile, getsourcefile, and getfile. The returned name is based on either module.__file__ or code.co_filename. I think the function should be kept and documented. 1. Assuming that both __file__ and co_filename are now normcased and normalized absolute paths, (and identical for functions,) then "os.path.normcase(os.path.abspath(_filename))" is a no-op returning _filename as is, and should be dropped. There is no longer a "guess at what the cwd was when a module was imported" in getabsfile itself. 2. getfile and getsourcefile do non-trivial switching and name processing that users would not get right if getabsfile were not present. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue12317> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
