svn+ssh://pythondev@svn.python.org/python/trunk
........
r78835 | victor.stinner | 2010-03-11 13:34:39 +0100 (jeu., 11 mars 2010) | 7 lines
Issue #7774: Set sys.executable to an empty string if argv[0] has been
set to an non existent program name and Python is unable to retrieve the real
program name.
Fix also sysconfig: if sys.executable is an empty string, use the current
working directory.
........
r78836 | victor.stinner | 2010-03-11 14:27:35 +0100 (jeu., 11 mars 2010) | 4 lines
Fix test_executable introduce in previous commit (r78835): Windows is able to
retrieve the absolute Python path even if argv[0] has been set to a non
existent program name.
........
r78837 | victor.stinner | 2010-03-11 14:46:06 +0100 (jeu., 11 mars 2010) | 3 lines
Another fix to test_executable() of test_sys: set the current working to avoid
the #7774 bug.
........
r78870 | victor.stinner | 2010-03-12 15:30:26 +0100 (ven., 12 mars 2010) | 1 line
NEWS: issue #7774 is related to Library (sys), not Core and Builtins
........
That's the title of the report, but the hole was probably plugged since
Python 2.0. See corresponding checkin to PC/getpathp.c: a crucial
precondition for joinpath() was neither documented nor verified, and there
are so many callers with so many conditional paths that no "eyeball
analysis" is satisfactory. Now Python dies with a fatal error if the
precondition isn't satisfied, instead of allowing a buffer overrun.
NOT TESTED! The Windows version of the patch was, but not this one. I
don't feel like waiting for someone to notice the patch I attached to the
bug report. If it doesn't compile, sorry, but fix it <wink>. If it
does compile, it's "obviously correct".
#!-scripts, only the filename part, and this can lead to incorrect
initialization of sys.path and sys.executable if there is another python
on $PATH before the one used in #!.
The fix was picked up from the darwinports crowd, thanks!
- new import hooks in import.c, exposed in the sys module
- new module called 'zipimport'
- various changes to allow bootstrapping from zip files
I hope I didn't break the Windows build (or anything else for that
matter), but then again, it's been sitting on sf long enough...
Regarding the latest discussions on python-dev: zipimport sets
pkg.__path__ as specified in PEP 273, and likewise, sys.path item such as
/path/to/Archive.zip/subdir/ are supported again.
#424002.
Refactor init_path_from_argv0() and rename to copy_absolute(); add
absolutize() which does the same in-place.
Clean up whitespace (leading tabs -> spaces, delete trailing
spaces/tabs).
