[EMAIL PROTECTED] wrote:
I checked in the contents of my multiprocessing.tar file and opened issues
#1 and #2.
I added a setup.py, disabled recv_bytes_into for now and fixed lots of
naming issues. The multiprocessing code is using the new names of the
threading module (current_thread, is_alive
Maybe we should backport those handy pep8 threading names ... ... Ok maybe
not.
On Oct 22, 2008 9:02am, Christian Heimes [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I checked in the contents of my multiprocessing.tar file and opened issues
#1 and #2.
I added a setup.py, disabled
Christian I just implemented the recv_bytes_into function with the old
Christian buffer protocol. All tests are passing on my Linux box
Christian (Ubuntu 8.04 with gcc 4.2, AMD64 processor).
Using Python v 2.6? So I don't need to horse around making
test_multiprocessing.py API
Maybe doing the modest amount of translation required of the 2.6 unit
tests so they run under 0.52 would help. See what fails and then see
what fixes correspond to fixing those failing tests.
Christian Sounds like a good plan. Let's get started! Are you going to
Christian
Christian Heimes wrote:
Nick Coghlan wrote:
As Jesse points out, some of that robustness comes from long-standing
bugs in the core getting fixed as a result of the addition of the
multiprocessing unit tests to the standard library test suite.
Not trying to discourage the project, just
Christian I like to make as much code of the trunk version compatible
Christian with 2.5 and 2.4 as possible. Let's see how far we can get
Christian with a bunch of macros and #ifdefs.
I'll follow your lead. ;-)
Skip
___
Python-Dev mailing
Jesse Do we want to start a google code project for this given all
Jesse three of us are interested in this? :)
Maybe the svn repo could grow a backports sibling of sandbox.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
Jesse I've not used svn.python.org for personal side/projects - also,
Jesse ideally the back port would be stand-alone and package-index
Jesse installable
I wouldn't call this really a personal/side project. OTOH, firing up a
Google Code project means you can admit project
Christian Oh h... Are you able to recall a list of the most important
Christian bug fixes? Maybe we can get the bug fixes into 2.5.3 before
Christian it's too late.
Maybe doing the modest amount of translation required of the 2.6 unit tests
so they run under 0.52 would help. See
On Fri, Oct 17, 2008 at 10:47 AM, [EMAIL PROTECTED] wrote:
Jesse I've not used svn.python.org for personal side/projects - also,
Jesse ideally the back port would be stand-alone and package-index
Jesse installable
I wouldn't call this really a personal/side project. OTOH, firing
[EMAIL PROTECTED] wrote:
Christian Oh h... Are you able to recall a list of the most important
Christian bug fixes? Maybe we can get the bug fixes into 2.5.3 before
Christian it's too late.
Maybe doing the modest amount of translation required of the 2.6 unit tests
so they run
Hi Skip,
I had been approached to do the exact same thing, are you trying to
back port the trunk version (2.6) or py3000?
On Thu, Oct 16, 2008 at 12:01 PM, Skip Montanaro
[EMAIL PROTECTED] wrote:
I'd like to try backporting the multiprocessing module to Python 2.4. My
first
problem appears
Also note, for python 2.4/2.5 you are going to *need* the patch to bug
http://bugs.python.org/issue874900
On Thu, Oct 16, 2008 at 12:34 PM, Jesse Noller [EMAIL PROTECTED] wrote:
Hi Skip,
I had been approached to do the exact same thing, are you trying to
back port the trunk version (2.6) or
I had been approached to do the exact same thing, are you trying to
back port the trunk version (2.6) or py3000?
I'm trying to backport from 2.6. It appears that the buffer stuff is
completely
new though (backported from Python 3.0).
S
___
Do we want to start a google code project for this given all three of
us are interested in this? :)
On Thu, Oct 16, 2008 at 3:28 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Skip Montanaro wrote:
I'd like to try backporting the multiprocessing module to Python 2.4. My
first
problem appears
On Thu, Oct 16, 2008 at 3:38 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Jesse Noller wrote:
Do we want to start a google code project for this given all three of
us are interested in this? :)
Do we need (yet) another Google code project? Isn't svn.python.org
sufficient for our needs? I'm
Skip Montanaro wrote:
(Note: I'm backporting because the Python 2.6 version appears to be much more
robust than the 0.52 third-party release.)
As Jesse points out, some of that robustness comes from long-standing
bugs in the core getting fixed as a result of the addition of the
multiprocessing
Nick Coghlan wrote:
As Jesse points out, some of that robustness comes from long-standing
bugs in the core getting fixed as a result of the addition of the
multiprocessing unit tests to the standard library test suite.
Not trying to discourage the project, just pointing out that it may not
be
18 matches
Mail list logo
