[Python-Dev] Remove str.find in 3.0?
Guido van Rossum
gvanrossum at gmail.com
Sat Aug 27 05:14:53 CEST 2005
On 8/26/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> I had one further thought. In addition to your excellent list of
> reasons, it would be great if these kind of requests were accompanied by
> a patch that removed the offending construct from the standard library.
Um? Are we now requiring patches for PYTHON THREE DOT OH proposals?
Raymond, we all know and agree that Python 3.0 will be incompatible in
many ways. range() and keys() becoming iterators, int/int returning
float, and so on; we can safely say that it will break nearly every
module under the sun, and no amount of defensive coding in Python 2.x
will save us.
> The most important reason for the patch is that looking at the context
> diff will provide an objective look at how real code will look before
> and after the change. This would make subsequent discussions
> substantially more informed and less anecdotal.
No, you're just artificially trying to raise the bar for Python 3.0
proposals to an unreasonable height.
> The second reason is that the revised library code becomes more likely
> to survive the transition to 3.0. Further, it can continue to serve as
> example code which highlights current best practices.
But we don't *want* all of the library code to survive. Much of it is
10-15 years old and in dear need of a total rewrite. See Anthony
Baxter's lightning talk at OSCON (I'm sure Google can find it for
you).
> This patch wouldn't take long. I've tried about a half dozen cases
> since you first posted. Each provided a new insight (zipfile was not
> improved, webbrowser was improved, and urlparse was about the same).
So it's neutral in terms of code readability. Great. Given all the
other advantages for the proposal (an eminent member of this group
just posted a buggy example :-) I'm now doubly convinced that we
should do it.
Also remember, the standard library is rather atypical -- while some
of it makes great example code, other parts of it are highly contorted
in order to either maintain backwards compatibility or provide an
unusually high level of defensiveness.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list