do not add directory of sys.argv[0] into sys.path

[wrobell]

BPO	946373
Nosy	@mwhudson, @birkenfeld, @pfmoore, @josiahcarlson
Files	python-noautosys.patch: do not add magically directory of sys.argv[0]

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-02-20.11:59:08.000>
created_at = <Date 2004-05-02.12:51:16.000>
labels = ['interpreter-core']
title = 'do not add directory of sys.argv[0] into sys.path'
updated_at = <Date 2006-02-20.11:59:08.000>
user = 'https://bugs.python.org/wrobell'

bugs.python.org fields:

activity = <Date 2006-02-20.11:59:08.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-05-02.12:51:16.000>
creator = 'wrobell'
dependencies = []
files = ['5959']
hgrepos = []
issue_num = 946373
keywords = ['patch']
message_count = 22.0
messages = ['45910', '45911', '45912', '45913', '45914', '45915', '45916', '45917', '45918', '45919', '45920', '45921', '45922', '45923', '45924', '45925', '45926', '45927', '45928', '45929', '45930', '45931']
nosy_count = 9.0
nosy_names = ['mwh', 'anthonybaxter', 'georg.brandl', 'jvr', 'paul.moore', 'isandler', 'jlgijsbers', 'josiahcarlson', 'wrobell']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue946373'
versions = []

[wrobell]

Python adds magically directory of sys.argv[0] into
sys.path, i.e.

>>> import sys
>>> sys.path
['', '/usr/lib/python23.zip', '/usr/share/python2.3',
'/usr/share/python2.3/plat-linux2',
'/usr/share/python2.3/lib-tk',
'/usr/lib/python2.3/lib-dynload',
'/usr/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages/gtk-2.0',
'/usr/share/python2.3/site-packages']

where '' (or /usr/bin when executed script is in
/usr/bin directory, etc.) is added automatically.

It is useful in many circumstances but fails when name
conflict occurs.
For example, create getpass.py or pdb.py scripts which
import getpass and pdb modules. Script names conflict
with modules names and modules
are not going to be imported because path to the
scripts is appended
into sys.path, so a script is imported instead of a module.

The solutions:

1. User of script with conflicting name (i.e.
   getpass.py or timeit.py)
   can set PYTHONPATH to system library path, i.e.
   /usr/lib/python2.3.
2. User can modify the script to delete site.path[0].
3. User can rename the script.
4. Python can be modified to not add magically
   directory of sys.argv[0].

The 1. is a tricky and not intuitive and quite funny:
set PYTHONPATH to system library path to import system
module (and only in
specific circumstances). ;-P

The 2. is a dirty hack: hey, we gonna import system
module, ain't it?

The 3. is, IMHO, not acceptable because there is more
than 200 python system modules, more in the future and
user cannot be forced to maintain script names blacklist.

The 4. is only acceptable, IMHO. It makes python more
inconvenient
but gives no trouble when names conflict occurs.
Moreover, fourth
solution makes python more standard with other languages
behaviour, i.e. one has to set CLASSPATH to load Java
classes.

Maybe there is another solution, but...

Patch attached.

[isandler]

Logged In: YES
user_id=971153

Would not this cause serious backward compatibility problems??

[anthonybaxter]

Logged In: YES
user_id=29957

I've been bitten by this before. See e.g. the shtoom.py
script clashing with the shtoom package. I used the hacky
approach of moving '' to the end of sys.path. While it would
be nice if this wasn't needed, I can't see this being
anything other than a backwards compatibility nightmare. It
will absolutely break a lot of things to change it.

[josiahcarlson]

Logged In: YES
user_id=341410

This "problem" will be fixed in Python 2.4 with the
introduction of absolute and relative import semantics as
given in PEP-328:

http://www.python.org/peps/pep-0328.html

As stated in the PEP, to use the obviously backwards
incompatible semantics, the future import will be used for
2.4 and 2.5, where in 2.6 it will become the default.

from __future__ import absolute_import

[jlgijsbers]

Logged In: YES
user_id=469548

wrobell, would you be willing to produce a version of the
patch which implements PEP-328? I'll close this patch if not.

[wrobell]

Logged In: YES
user_id=387193

i will not provide the patch for 328, so closing this issue

[wrobell]

Logged In: YES
user_id=387193

I am opening it again to discuss it a little more...
Question to Josiah Carlson or anybody who can answer:

How PEP-328 is going to solve problem I have described?

If I name my script email.py, which will try to import email
standard Python
package. Then run the script, it will import itself instead
of Python package,
because directory where email.py is installed is added to
sys.path.

[josiahcarlson]

Logged In: YES
user_id=341410

If the entirety of PEP-328 made it into Python 2.4 (I don't
have an installation of 2.4, so don't know), to import your
'email.py' module, you would use 'from . import email' after
enabling the absolute import semantics with 'from __future__
import absolute_import'. You would then import the standard
email package with 'import email'.

Is this not clear by reading PEP-328?

[wrobell]

Logged In: YES
user_id=387193

But the problem is not with naming of my modules/packages
(part about relative import of modules I do understand, of
course), but with script naming.

For example consider script:

  #!/usr/bin/python
   import email
   print 1

And name the script email.py, then run it, please. Python
tries to be too smart (IMHO) and variable sys.path is
polluted with directory of email.py script, therefore
standard email Python package will not be imported.

[josiahcarlson]

Logged In: YES
user_id=341410

If you were to make your 'email.py' file contain the
following...

#!/user/bin/python
from __future__ import absolute_import
import email
print 1

It should import the email package.

[jvr]

Logged In: YES
user_id=92689

That doesn't follow at all. The script email.py will _still_ be found first instead
of the email module. Like wrobell, I don't see what this has _anything_ to do
with relative vs. absolute imports.

While a common newbie gotcha, I don't think it's worth the trouble to try to
"fix" this. Recommending "won't fix".