>>> help(inspect.getabsfile) could be copied

getabsfile(object, _filename=None)
    Return an absolute path to the source or compiled file for an object.
    
    The idea is for each object to have a unique origin, so this routine
    normalizes the result as much as possible.

This shouldn't be a dependency. The function is already implemented, it just needs to be documented.

It technically doesn't need to be a dependency, but if __file__ goes absolute then the point of the function becomes moot and thus shouldn't get documented as it is then pointless (and honestly I don't trust any code that tries to guess at what the cwd was when a module was imported).

@pitrou
Hi, Can I work on this issue?

Hi @corona10, Antoine's message is from 2013 and inspect.getabsfile() is still not documented, I think it's safe to say he's not working on it.

You can work on the issue and open a new PR on GitHub when you think it is ready for review :)

3.6 is also on security-fix-only status

@terry.reedy
I submited the PR 11786 for this issue.
If you are okay can you take a look please?
Thanks!

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.