"Raymond Hettinger" <raymond.hettinger@verizon.net> wrote:
[Guido]
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.
Perhaps...
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. - Josiah