[Python-Dev] Further PEP 8 compliance issues in threading and multiprocessing

Jesse Noller jnoller at gmail.com
Tue Sep 2 16:58:59 CEST 2008

On Tue, Sep 2, 2008 at 10:03 AM, Nick Coghlan <ncoghlan at 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


More information about the Python-Dev mailing list