Suppose I have a file profile.py in the same directory as the file I am running (say test.py)

Let the contents of the files be:

profile.py:
raise Exception

test.py:
import cProfile

now if I run test.py

$ python test.py
Traceback (most recent call last):
  File "test.py", line 1, in <module>
    import cProfile
  File "/usr/lib/python3.7/cProfile.py", line 10, in <module>
    import profile as _pyprofile
  File "/home/username/profile.py", line 1, in <module>
    raise Exception
Exception

The file profile.py in '/usr/lib/python3.7' should have been loaded. This would also happen if test.py imported a module or package which imported cProfile.

The only possible way of avoiding this problem completely is by ensuring that the name of any the python files don't match a builtin python file or the name of any installed package.

A python user can't be expected to know the name of every possible file in the Python standard library. Maybe the current working directory should be removed from sys.path when importing from within another module not in the same directory.

hi you are obsverving that because current working directory is set *first* in sys.path as a commodity

you can avoid that with

import sys,os
sys.path.remove( os.getcwd() )

at the start of your program. 

otherwise usually it is wise to put user module in a package and choose its name with care.

> A python user can't be expected to know the name of every possible file in the Python standard library. Maybe the current working directory should be removed from sys.path when importing from within another module not in the same directory.

I think there was a similar discussion about this since Perl did a related change : https://mail.python.org/pipermail/python-ideas/2017-June/045842.html

My contention is that this behaviour breaks the Principle of Least Astonishment.

In the particular example I gave, the user doesn't know (and can't be expected to know) the existence of a module called profile in the standard library. Here the user is not explicitly importing profile. The user can't be expected to know which submodules are imported by the modules they use. Hence they wouldn't expect another file sitting in the same directory to get imported when they are not explicitly importing it.

on 2018-12-02 10:35, pmpp said:
> you can avoid that with

> import sys,os
> sys.path.remove( os.getcwd() )

> at the start of your program. 

completely removing cwd from sys.path would disable the option of importing user modules.

Any method of fixing this would be backwards incompatible, and will break some (most likely badly written) code.

My hack solution was to have cwd in sys.path only if __name__ is '__main__'.

Already covered in issue29929: https://bugs.python.org/issue29929.

Thanks xtreak for the link to the message thread.

PEP 432 seems to have methods to resolve this.

Currently if the code doesn't access to .local, one can use the -I commandline option and use from . import module for local imports.