[Python-3000] [Python-3000-checkins] r64217 - in python/branches/py3k/Lib: bsddb/test/test_associate.py bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py idlelib/rpc.py idlelib/run.py socketserver.py test/test_threadedtemp

[Georg Brandl]

Guido van Rossum schrieb:
> On Thu, Jun 12, 2008 at 11:32 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>> Guido van Rossum schrieb:
>>>
>>> It's water under the bridge now, but IMO it was too rash to *remove*
>>> the old threading API from Py3k, and doubly rash to do so one day
>>> before the beta release. Running up to a release (whether alpha, beta
>>> or final) we should practice extra restraint, not rush to get things
>>> in right before the deadline. Let's all be more careful the rest of
>>> this release cycle! (I think it wasn't just Benjamin who raced to get
>>> things in...)
>>
>> Also, for any method or module renaming, there is no way around a full
>> grep through the code base to really catch all uses of the old API.
> 
> Eh? Even a full grep won't reveal 3rd party uses of the old API. While
> 3.x is intentionally breaking some things, this is not (and was never
> meant to be) as a blanket approval to break any API we feel like
> breaking. Each specific breakage must have a good motivation, e.g. the
> old API is confusing, or inefficient, or disallows certain uses --
> non-PEP-8-conformance alone is not enough! In addition, each specific
> breakage must be weighed against the cost of updating 3rd party code,
> and whether a good (or at least fair) automatic conversion can be
> added to 2to3.

You misunderstand. This wasn't meant as a justification for doing these
specific renamings, but applies to every renaming, e.g. those done for
PEP 3108. Completely regardless of 3rd party code, the code base itself
must be cleanly adapted to the new name.

 >> It may be tedious, especially with common names, but such bugs really
 >> must be avoided as they can easily be -- I still could find uses of
 >> old-style threading names, even in the stdlib. (Fixed in r64222.)
 >
 > All the more reason not to rush into API renamings without due process
 > and lots of discussion. Let's err on the side of the status quo --
 > otherwise we'll never be ready for beta.

No argument here -- I wasn't speaking in favor of more renamings.

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.