2.4->2.5 current directory change?

[Chris Mellon]

This appears to be a change in behavior from Python 2.4 to Python 2.5,
which I can't find documented anywhere. It may be windows only, or
related to Windows behavior.

In 2.4, the current directory (os.curdir) was on sys.path. In 2.5, it
appears to be the base directory of the running script. For example,
if you execute the file testme.py in your current working directory,
'' is on sys.path. If you execute c:\Python25\Scripts\testme.py, '' is
*not* on sys.path, and C:\Python25\Scripts is.

That means if you run a Python script located in another directory,
modules/etc in your current working directory will not be found. This
makes .py scripts in the PYTHONHOME\Scripts file moderately useless,
because they won't find anything in the current working directory.
I first noticed this because it breaks Trial, but I'm sure there are
other scripts affected by it. Is this desirable behavior? Is there
anything to work around it except by pushing os.curdir onto sys.path?

[Ziga Seilnacht]

On Feb 26, 7:44 pm, "Chris Mellon" <[e-mail]:

This appears to be a change in behavior from Python 2.4 to Python 2.5,
which I can't find documented anywhere. It may be windows only, or
related to Windows behavior.

In 2.4, the current directory (os.curdir) was on sys.path. In 2.5, it
appears to be the base directory of the running script. For example,
if you execute the file testme.py in your current working directory,
'' is on sys.path. If you execute c:\Python25\Scripts\testme.py, '' is
*not* on sys.path, and C:\Python25\Scripts is.

That means if you run a Python script located in another directory,
modules/etc in your current working directory will not be found. This
makes .py scripts in the PYTHONHOME\Scripts file moderately useless,
because they won't find anything in the current working directory.

I first noticed this because it breaks Trial, but I'm sure there are
other scripts affected by it. Is this desirable behavior? Is there
anything to work around it except by pushing os.curdir onto sys.path?

The change was intentional and is mentioned in the NEWS file:

- Patch #1232023: Stop including current directory in search path
on Windows.

This unifies Python's behaviour across different platforms; the
docs always said that the current directory is inserted *only*
if the script directory is unavailable:

As initialized upon program startup, the first item of this list,
path[0], is the directory containing the script that was used to
invoke the Python interpreter. If the script directory is not
available (e.g. if the interpreter is invoked interactively or
if the script is read from standard input), path[0] is the empty
string, which directs Python to search modules in the current
directory first. Notice that the script directory is inserted
before the entries inserted as a result of PYTHONPATH.

The old behaviour was never intentional and wasn't desired,
because users could break an application simply by running it
from a directory that contained inappropriately named files.

For details see the bug report and patch submission:
http://www.python.org/sf/1526785
http://www.python.org/sf/1232023

Ziga

[Chris Mellon]

On 26 Feb 2007 13:00:55 -0800, Ziga Seilnacht <zi************@gmail.comwrote:

On Feb 26, 7:44 pm, "Chris Mellon" <[e-mail]:

This appears to be a change in behavior from Python 2.4 to Python 2.5,
which I can't find documented anywhere. It may be windows only, or
related to Windows behavior.

In 2.4, the current directory (os.curdir) was on sys.path. In 2.5, it
appears to be the base directory of the running script. For example,
if you execute the file testme.py in your current working directory,
'' is on sys.path. If you execute c:\Python25\Scripts\testme.py, '' is
*not* on sys.path, and C:\Python25\Scripts is.

That means if you run a Python script located in another directory,
modules/etc in your current working directory will not be found. This
makes .py scripts in the PYTHONHOME\Scripts file moderately useless,
because they won't find anything in the current working directory.

I first noticed this because it breaks Trial, but I'm sure there are
other scripts affected by it. Is this desirable behavior? Is there
anything to work around it except by pushing os.curdir onto sys.path?

The change was intentional and is mentioned in the NEWS file:

- Patch #1232023: Stop including current directory in search path
on Windows.

This unifies Python's behaviour across different platforms; the
docs always said that the current directory is inserted *only*
if the script directory is unavailable:

As initialized upon program startup, the first item of this list,
path[0], is the directory containing the script that was used to
invoke the Python interpreter. If the script directory is not
available (e.g. if the interpreter is invoked interactively or
if the script is read from standard input), path[0] is the empty
string, which directs Python to search modules in the current
directory first. Notice that the script directory is inserted
before the entries inserted as a result of PYTHONPATH.

The old behaviour was never intentional and wasn't desired,
because users could break an application simply by running it
from a directory that contained inappropriately named files.

For details see the bug report and patch submission:
http://www.python.org/sf/1526785
http://www.python.org/sf/1232023

Ziga

Considering that it's a backwards incompatible breaking change
(although I understand why it was done), you'd think it deserved
mention in the more prominent "Whats new in Python 2.5" section on the
website, in addition to a one-liner in the NEWS file. Ah well, while
I'm sure I'm not the only one who ran into it, it doesn't seem to be
causing mass calamity and I know now.

[Ziga Seilnacht]

Chris Mellon wrote:

Considering that it's a backwards incompatible breaking change
(although I understand why it was done), you'd think it deserved
mention in the more prominent "Whats new in Python 2.5" section on the
website, in addition to a one-liner in the NEWS file. Ah well, while
I'm sure I'm not the only one who ran into it, it doesn't seem to be
causing mass calamity and I know now.

I guess that most of the scripts that want curdir on path and work
on different platforms already have to include current directory
manualy. Twisted's preamble in Trial does that too, but it is too
cautious to work on Windows (line 15 in the trial script):

if hasattr(os, "getuid") and os.getuid() != 0:
sys.path.insert(0, os.curdir)

Maybe that can be changed to:

if not hasattr(os, "getuid") or os.getuid() != 0:
sys.path.insert(0, os.curdir)

I'm no security expert, and I don't know if there are other
operating systems that don't have getuid() function but have
a superuser, but this doesn't look that less secure to me.

Ziga