[Python-Dev] Remove str.find in 3.0?
jcarlson at uci.edu
Sun Aug 28 20:31:46 CEST 2005
"Raymond Hettinger" <raymond.hettinger at verizon.net> wrote:
> > Another observation: despite the derogatory remarks about regular
> > expressions, they have one thing going for them: they provide a higher
> > level of abstraction for string parsing, which this is all about.
> > (They are higher level in that you don't have to be counting
> > characters, which is about the lowest-level activity in programming --
> > only counting bytes is lower!)
> > Maybe if we had a *good* way of specifying string parsing we wouldn't
> > be needing to call find() or index() so much at all! (A good example
> > is the code that Raymond lifted from ConfigParser: a semicolon
> > preceded by whitespace starts a comment, other semicolons don't.
> > Surely there ought to be a better way to write that.)
> A higher level abstraction is surely the way to go.
> Of course, if this idea survives the day, then I'll meet my own
> requirements and write a context diff on the standard library. That
> ought to give a good indication of how well the new methods meet
> existing needs and whether the resulting code is better, cleaner,
> clearer, faster, etc.
My first thought when reading the proposal was "that's just
str.split/str.rsplit with maxsplit=1, returning the thing you split on,
with 3 items always returned, what's the big deal?" Two second later it
hit me, that is the big deal.
Right now it is a bit of a pain to get string.split to return consistant
numbers of return values; I myself have used:
l,r = (x.split(y, 1)+[''])[:2]
...around 10 times - 10 times more than I really should have.
Taking a wander through my code, this improves the look and flow in
almost every case (the exceptions being where I should have rewritten to
use 'substr in str' after I started using Python 2.3). Taking a walk
through examples of str.rfind at koders.com leads me to believe that
.partition/.rpartition would generally improve the flow, correctness,
and beauty of code which had previously been using .find/.rfind.
I hope the idea survives the day.
More information about the Python-Dev