On Tue, Sep 2, 2008 at 10:03 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Antoine Pitrou wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
Given the proximity of RC1, Antoine's option 3 (leaving the capitalised factory functions in both multiprocessing and threading APIs) is actually sounding pretty appealing to me at the moment.
I was actually suggesting this course for the threading module, whose API has existed for a lot of time now, but I think it would be better to clean up multiprocessing before its first stable relase. But the issue of time and manpower starts being a bit critical :)
Unfortunately, that's where the whole "close to a drop-in replacement for threading" concept brings additions to the threading module API back into play.
If I'd realised this a bit sooner I probably would have been pushing for it to be dealt with for 2.6/3.0, but given that it's the kind of change that we can easily do through the normal API deprecation process, I'm really not comfortable messing with it this close to the release (particularly after Jesse found a problem with the seemingly innocent change to the multiprocessing implementation in issue 3589).
Cheers, Nick.
Yes, the innocuous change in 3589 - which really made a lot of sense, introduced a bug that didn't get caught until a complete make distclean; rebuild - that actually scared me off of the idea of addressing 3589 right now. I would move 3589 to 2.7/3.1 and file an additional bug for any further pep8-ifying to both the threading and mp APIs against 2.7 and 3.1 -jesse