Nick Coghlan added the comment:
Long term fix: runpy.run_path and runpy.run_module need to accept a target
parameter, multiprocessing needs to use the appropriate one based on whether or
not __main__.__spec__ is None.
Short term (3.4) fix: we can expose a private API in runpy akin to the
Brett Cannon added the comment:
Created http://bugs.python.org/issue19978 to track using runpy.run_path in 3.5.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
Roundup Robot added the comment:
New changeset cea42629ddf5 by Brett Cannon in branch 'default':
Issue #19946: Raise ImportError when the main module cannot be found
http://hg.python.org/cpython/rev/cea42629ddf5
--
nosy: +python-dev
___
Python
Olivier Grisel added the comment:
Why has this issue been closed? Won't the spawn and forkserver mode work in
Python 3.4 for Python program started by a Python script (which is probably the
majority of programs written in Python under unix)?
Is there any reason not to use the
Brett Cannon added the comment:
Multiple questions from Oliver to answer.
Why has this issue been closed?
Because the decided issue of this bug -- raising AttributeError over
ImportError -- was fixed.
Won't the spawn and forkserver mode work in Python 3.4 for Python program
started by a
Olivier Grisel added the comment:
The semantics are not going to change in python 3.4 and will just stay as
they were in Python 3.3.
Well the semantics do change: in Python 3.3 the spawn and forkserver modes did
not exist at all. The spawn mode existed but only implicitly and only under
Brett Cannon added the comment:
I'm sorry, Oliver, you are simply going to have to wait for Python 3.5 at this
point to get the new semantics you want.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19946
Antoine Pitrou added the comment:
I'm sorry, Oliver, you are simply going to have to wait for Python 3.5
at this point to get the new semantics you want.
Side note: it's Olivier, not Oliver.
--
___
Python tracker rep...@bugs.python.org
Olivier Grisel added the comment:
I can wait (or monkey-patch the stuff I need as a temporary workaround in my
code). My worry is that Python 3.4 will introduce a new feature that is very
crash-prone.
Take this simple program that uses the newly introduced `get_context` function
(the same
Antoine Pitrou added the comment:
Let's reopen, shall we? If not for 3.4, at least for 3.5.
It's likely that multiprocessing needs a __main__ simply because it needs a way
to replicate the parent process' state in the child (for example, the set of
imported modules, the logging configuration,
Olivier Grisel added the comment:
For Python 3.4:
Maybe rather than raising ImportError, we could issue warning to notify the
users that names from the __main__ namespace could not be loaded and make the
init_module_attrs return early.
This way a multiprocessing program that only calls
Olivier Grisel added the comment:
I agree that a failure to lookup the module should raise an explicit exception.
Second, there is no way that 'nosetests' will ever succeed as an import
since, as Oliver pointed out, it doesn't end in '.py' or any other
identifiable way for a finder to know
Olivier Grisel added the comment:
what is sys.modules['__main__'] and sys.modules['__main__'].__file__ if you
run under nose?
$ cat check_stuff.py
import sys
def test_main():
print(sys.modules['__main__']=%r
% sys.modules['__main__'])
Olivier Grisel added the comment:
Note however that the problem is not specific to nose. If I rename my initial
'check_forserver.py' script to 'check_forserver', add the '#!/usr/bin/env
python' header and make it 'chmod +x' I get the same crash.
So the problem is related to the fact that
Olivier Grisel added the comment:
Here is a patch that uses `imp.load_source` when the first importlib name-based
lookup fails.
Apparently it fixes the issue on my box but I am not sure whether this is the
correct way to do it.
--
keywords: +patch
Added file:
Nick Coghlan added the comment:
Rerunning main in the subprocess has always been a slightly dubious feature
of multiprocessing, but IIRC it's a necessary hack to ensure pickle
compatibility for things defined in __main__. Using runpy.run_path would
be a better solution, but we'll need to add the
Brett Cannon added the comment:
So at the bare minimum, the multiprocessing code should raise an ImportError
when it can't find the spec for the module to help debug this kind of thing.
Also that typo should get fixed.
Second, there is no way that 'nosetests' will ever succeed as an import
Richard Oudkerk added the comment:
I guess this is a case where we should not be trying to import the main module.
The code for determining the path of the main module (if any) is rather crufty.
What is sys.modules['__main__'] and sys.modules['__main__'].__file__ if you run
under nose?
Eric Snow added the comment:
There is definitely room for improvement relative to module specs and __main__
(that's the topic of issue #19701). That issue is waiting for __main__ to get
a proper spec (see issues #19700 and #19697).
--
___
Python
19 matches
Mail list logo
