Nick Coghlan added the comment: If main.c doesn't handle sys.exit() correctly for code run via RunMainFromImporter, then that's a problem with the main function - it will happen regardless of whether it is runpy.py or application code that calls sys.exit. But as far as I can tell, it handles it just fine - the SystemExit exception is converted to an error return from PyObject_Call, which then flows back up the C stack as an error return from each relevant function call in main.c (until it gets back to the shell with a non-zero return code from the main function).
And I don't understand your complaint about the Py_None return conflicting with the comment on that if statement: PyImport_GetImporter will return Py_None for a directory name, as directories are handled by the builtin machinery. If PyImport_GetImporter fails completely it will return NULL - if the function returns anything else, then PyImport thinks the passed in string is a legitimate sys.path entry (i.e. usable as an import source). The *only* difference issue3125 (or Brett's import_in_py branch) would make to any of this is that PyImport_GetImporter won't return Py_None anymore. In either case, the additional try/except in runpy would still be necessary in order to intercept the ImportError when looking for the module to be executed and convert it to something a bit more explicit. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1877> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
