On Thu, 08 Sep 2016 at 08:44:54 -0700, Russ Allbery wrote: > I don't see any inherent reason why that > should have to be the case (other than, of course, that this Python > behavior is long-standing and lots of software depends on it
I suspect that Python scripts relying on their own directory being put on sys.path are going to be a lot more common than Perl scripts relying on the current working directory being in @INC. The Perl script author doesn't (usually) control the current working directory at the time of invocation, whereas the Python script author usually does control where the script gets installed relative to its required library. In particular, this is quite a common idiom, because it's one of the few ways you can have private Python modules (and hence not have to care about having a stable API, which isn't in-scope for every project) without explicitly setting sys.path to a value hard-coded at install time: Source tree: ~/src/myapp or whatever |- myapp/ | \- __init__.py (etc.) \- run (a #!/usr/bin/env python script including "import myapp") Installed: /usr/bin/myapp \- myapp -> /usr/share/myapp/run (symlink) /usr/share/myapp |- myapp/ | \- __init__.py (etc.) \- run When developing, you run "./run --args", and Python puts the equivalent of $(pwd) on sys.path, and uses $(pwd)/myapp for "import myapp". When installed, you run "myapp --args" and Python follows the symlink, finds /usr/share/myapp/run, puts /usr/share/myapp on sys.path, and uses /usr/share/myapp/myapp for "import myapp". S