Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1877
___
___
Python-bugs-list
Nick Coghlan added the comment:
We don't want to restore Python 2.5 behaviour - directories containing a
__main__.py file are meant to be executable in 2.6. With your proposed
change test_cmd_line_script will fail its directory execution tests
(since those rely on the default importer to find
Nick Coghlan added the comment:
I've checked in friendlier error messages as r60955
Examples (paths somewhat redacted):
$ ./python bob
./python: can't open file 'bob': [Errno 2] No such file or directory
$ ./python .
/devel/python/python: can't find '__main__.py' in '.'
$ ./python Lib
Alexander Belopolsky added the comment:
Nick,
I understand the __main__.py issue now, but I still don't like your
approach. Allowing RunMainFromImporter to call exit and never return
does not feel right. (A minor problem is that objects on the C stack do
not get deleted.) Without a check
Alexander Belopolsky added the comment:
I think a more elegant solution will be possible if issue2135 patch is
accepted. I suggest to reopen this issue for Py3k pending resolution of
issue2135.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1877
Alexander Belopolsky added the comment:
Nick, you are right about sys.exit(). I did to much C programming
lately and forgot that sys.exit() does not exit. :-)
I understood your comment as saying that 'importer' points to a valid
importer. Now I understand that with the present state of the
Nick Coghlan added the comment:
The mutation of sys.path is deliberate - the use case is to allow the
interpreter to execute a zipfile directly and have access to all of the
Python modules and packages bundled along with __main__.py. Supporting
execution of directories as well makes it much
Alexander Belopolsky added the comment:
Actually, a very simple change restores python2.5 behavior:
===
--- Modules/main.c (revision 60941)
+++ Modules/main.c (working copy)
@@ -187,6 +187,7 @@
if ((argv0 =
Alexander Belopolsky added the comment:
I have found relevant documentation in a comment preceding get_path_importer
definition:
... traverse path_hooks until a hook is found
that can handle the path item. Return None if no hook could;
this tells our caller it should fall back to
Changes by Christian Heimes:
--
components: +Library (Lib)
keywords: +easy
priority: - normal
type: - behavior
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1877
__
New submission from Georg Brandl:
[EMAIL PROTECTED] ~/devel/python ./python Lib
Traceback (most recent call last):
File Lib/runpy.py, line 99, in _run_module_as_main
loader, code, fname = _get_module_details(mod_name)
File Lib/runpy.py, line 86, in _get_module_details
raise
Georg Brandl added the comment:
No idea about the easy -- I haven't really looked at the code, but
amending the error message would be a good thing.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1877
__
Nick Coghlan added the comment:
In what sense is this being flagged as easy? All the runpy code knows at
this point is that it asked the import system for the __main__ module's
code object and didn't get one. __main__ always exists, so the module is
definitely able to be found - working out
Nick Coghlan added the comment:
I removed the easy tag. I'll try to come up with some ideas for making
the error message more helpful without making it misleading.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1877
__
14 matches
Mail list logo
