[Python-Dev] __file__ is not always an absolute path

Nick Coghlan ncoghlan at gmail.com
Mon Feb 8 13:45:43 CET 2010

Antoine Pitrou wrote:
> Barry Warsaw <barry <at> python.org> writes:
>>> exarkun <at> boson:~$ python -m timeit -s 'from os import getcwd' 'getcwd()'
>>> 1000000 loops, best of 3: 1.02 usec per loop
> [...]
>> I'd like to see the effect on command line scripts that are run often and then
>> exit, e.g. Bazaar or Mercurial.  Start up time due to import overhead seems to
>> be a constant battle for those types of projects.
> If os.getcwd() is only called once when "normalizing" sys.path, and if it just
> takes one microsecond, I don't really see the point. :-)

The problem is that having '' as the first entry in sys.path currently
means "do the import relative to the current directory". Unless we want
to change the language semantics so we stick os.getcwd() at the front
instead of '', then __file__ is still going to be relative sometimes.

Alternatively, we could special case those specific imports to do
os.getcwd() at the time of the import. That won't affect the import
speed significantly for imports from locations other than '' (i.e. most
of them) and will more accurately reflect the true meaning of __file__
in that case (since we put the module in sys.modules, future imports
won't see different versions of that module even if the working
directory is changed, so the relative value for __file__ becomes a lie
as soon as the working directory changes)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list