[Python-Dev] PEP 371: Additional Discussion

[Guido van Rossum]

On Tue, Jun 3, 2008 at 6:48 PM, Raymond Hettinger <python at rcn.com> wrote:
> I think its a small disaster to have the APIs be almost
> the same but with trivial differences in spelling.

Strong words -- and it now seems just your gut feelings against mine.
I have come to trust mine quite a bit.

> PEP 8 is a nice guideline but it seems to have become
> an end in an of itself.  The point of the PEP is to use
> consistency as a memory cue, but having two sets of
> method names that are almost parallel but spelled
> differently is at odds with that goal.

PEP 8 helps by making exact method spellings easier to remember. The
recommendation against abbreviations also comes from this goal. It
should be used for all new APIs. (Except of course when adding to a
set of existing APIs that use a different convention.)

I consider multiprocessing a new API -- while it bears a superficial
resemblance with the threading API the similarities are just that, and
it should not be constrained by mistakes in that API.

> Moving both modules to PEP 8 compliance makes more
> sense, but I would hope that gets left for Py3.0.  There's
> too much existing code, too many existing tutorials, and
> too many hardcopy books already in Py2.x.

It was decided not to "fix" APIs for Py3k beyond the module naming
issue. We can add a new PEP-8-compliant API to the threading module in
3.0 but the old API should stay for another release or more. I'm
neutral on whether it makes sense to backport the new threading.py
APIs to 2.6.

--Guido

> Raymond
>
>
> ----- Original Message ----- From: "Guido van Rossum" <guido at python.org>
> To: "Mike Klaas" <mike.klaas at gmail.com>
> Cc: <python-dev at python.org>
> Sent: Tuesday, June 03, 2008 4:21 PM
> Subject: Re: [Python-Dev] PEP 371: Additional Discussion
>
>
> I'm curious why people thing that strict API compatibility is
> important at all. In my view, having the APIs be similar is really
> helpful because it helps people quickly understand what you can do
> with the new module. But I honestly don't expect anyone to take an
> existing app using threading and turning it into one using
> multiprocessing by changing a single line. There are too many things
> that threads let you do that aren't supported by processes (e.g.
> shared mutable objects protected by locks).
>
> IMO the multiprocessing module should only provide a PEP-8-compliant
> API, and optionally we could start adding such an API to the threading
> module. Strict compatibility with the Java API really isn't important
> there either -- that's just how I got started with it, and I gladly
> admit I went overboard there.
>
> --Guido
>
> On Tue, Jun 3, 2008 at 4:01 PM, Mike Klaas <mike.klaas at gmail.com> wrote:
>>
>> On 3-Jun-08, at 3:53 PM, Benjamin Peterson wrote:
>>
>>> On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <jnoller at gmail.com> wrote:
>>>>
>>>> Also - we could leave in stubs to match the threading api - Guido, David
>>>> Goodger and others really prefer not to continue the "broken" API of the
>>>> threading API
>>>
>>> I agree that the threading the the pyprocessing APIs should be PEP 8
>>> compliant, but I think 2 APIs is almost worse than one wrong one.
>>
>> A cleaner way to effectuate the transition would be to leave the camelCase
>> API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules),
>> and provide threading3k and multiprocessing3k modules in 2.6 that façade
>> the
>> 2.6 API with the PEP 8 API.
>>
>> 2to3 would rewrite 'import threading3k' to 'import threading' and
>> everything
>> would work (it would warn about 'import threading' in 2.6 code).
>>
>> -Mike
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/python%40rcn.com
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)