"Raymond Hettinger" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
