Il Thu, 17 Feb 2011 18:31:59 -0500, Matt Chaput ha scritto:
>
> The problem is that with both "python setup.py tests" and "nosetests",
> Maybe multiprocessing is starting new Windows processes by copying the
> command line of the current process? But if the command line is
> "nosetests", it's
On 17/02/2011 8:22 PM, phi...@semanchuk.com wrote:
Hi Matt,
I assume you're aware of this documentation, especially the item
entitled "Safe importing of main module"?
http://docs.python.org/release/2.6.6/library/multiprocessing.html#windows
Yes, but the thing is my code isn't __main__, my uni
On 18/02/2011 2:54 AM, Terry Reedy wrote:
On 2/17/2011 6:31 PM, Matt Chaput wrote:
Does anyone know the "right" way to write a unit test for code that uses
multiprocessing on Windows?
I would start with Lib/test/test_multiprocessing.
Good idea, but on the one hand it doesn't seem to be doing
On 2/17/2011 6:31 PM, Matt Chaput wrote:
Does anyone know the "right" way to write a unit test for code that uses
multiprocessing on Windows?
I would start with Lib/test/test_multiprocessing.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Quoting Matt Chaput :
Does anyone know the "right" way to write a unit test for code that
uses multiprocessing on Windows?
The problem is that with both "python setup.py tests" and
"nosetests", when they get to testing any code that starts Processes
they spawn multiple copies of the testi
Does anyone know the "right" way to write a unit test for code that uses
multiprocessing on Windows?
The problem is that with both "python setup.py tests" and "nosetests",
when they get to a multiprocessing test they spawn multiple copies of
the testing suite. The test runner in PyDev works pr
Does anyone know the "right" way to write a unit test for code that uses
multiprocessing on Windows?
The problem is that with both "python setup.py tests" and "nosetests",
when they get to testing any code that starts Processes they spawn
multiple copies of the testing suite (i.e. the new proc
