On Thu, Aug 24, 2006 at 03:48:57PM +0200, Fredrik Lundh wrote: > Michael Chermside wrote: > > >> WOW, I love partition. In all the instances that weren't a simple "in" > >> test I ended up using [r]partition. In some cases one of the returned > >> strings gets thrown away but in those cases it is guaranteed to be small. > >> The new code is usually smaller than the old and generally clearer. > > > > Wow. That's just beautiful. This has now convinced me that dumping > > [r]find() (at least!) and pushing people toward using partition will > > result in pain in the short term (of course), and beautiful, readable > > code in the long term. > > note that partition provides an elegant solution to an important *subset* of > all > problems addressed by find/index. > > just like lexical scoping vs. default arguments and map vs. list > comprehensions, > it doesn't address all problems right out of the box, and shouldn't be > advertised > as doing that. >
After some benchmarking find() can't go away without really hurting readline() performance. partition performs as well as find for small lines but for large lines the extra copy to concat the newline separator is a killer (twice as slow for 50k char lines). index has the opposite problem as the overhead of setting up a try block makes 50 char lines twice as slow even when the except clause is never triggered. A version of partition that returned two arguments instead of three would solve the problem but that would just be adding more functions to remove the two find's or adding behavior flags to partition. Ick. Most uses of find are better off using partition but if this one case can't be beat there must be others too. -Jack _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
