[issue35375] name shadowing while a module tries to import another

[Sriram Krishna]

Sriram Krishna  added the comment:

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.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35375] name shadowing while a module tries to import another

[Sriram Krishna]

Sriram Krishna  added the comment:

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__'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35375] name shadowing while a module tries to import another

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

> 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

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35375] name shadowing while a module tries to import another

[pmpp]

pmpp  added the comment:

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.

--
nosy: +pmpp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35375] name shadowing while a module tries to import another

[Sriram Krishna]

New submission from Sriram Krishna :

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 
import cProfile
  File "/usr/lib/python3.7/cProfile.py", line 10, in 
import profile as _pyprofile
  File "/home/username/profile.py", line 1, in 
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.

--
components: Interpreter Core
messages: 330874
nosy: ksriram
priority: normal
severity: normal
status: open
title: name shadowing while a module tries to import another
type: behavior
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com