[Python-Dev] Proof of the pudding: str.partition()

Phillip J. Eby pje at telecommunity.com
Wed Aug 31 15:40:15 CEST 2005


At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote:
>Raymond's original definition for partition() did NOT support any
>of the following:
>
>    (*) Regular Expressions

This can be orthogonally added to the 're' module, and definitely should 
not be part of the string method.


>    (*) Ways to generate just 1 or 2 of the 3 values if some are
>        not going to be used

Yep, subscripting and slicing are more than adequate to handle *all* of 
those use cases, even the ones that some people have been jumping through 
odd hoops to express:

     before = x.partition(sep)[0]
     found  = x.partition(sep)[1]
     after  = x.partition(sep)[2]

     before, found = x.partition("foo")[:2]
     found,  after = x.partition("foo")[1:]
     before, after = x.partition("foo")[::2]

Okay, that last one is maybe a little too clever.  I'd personally just use 
'__' or 'DONTCARE' or something like that for the value(s) I didn't care 
about, because it  actually takes slightly less time to unpack a 3-tuple 
into three function-local variables than it does to pull out a single 
element of the tuple, and it's almost twice as fast as taking a slice and 
unpacking it into two variables.

So, using three variables is both faster *and* easier to read than any of 
the variations anybody has proposed, including the ones I just showed above.


>    (*) Clever use of indices to avoid copying strings
>    (*) Behind-the-scenes tricks to allow repeated re-partitioning
>        to be faster than O(n^2)

Yep, -1 on these.


>The absence of these "features" is a GOOD thing. It makes the
>behavior of partition() so simple and straightforward that it is
>easily documented and can be instantly understood by a competent
>programmer. I *like* keeping it simple. In fact, if anything, I'd
>give UP the one fancy feature he chose to include:
>
>    (*) An rpartition() function that searches from the right
>
>...except that I understand why he included it and am convinced
>by the arguments (use cases can be demonstrated and people would
>expect it to be there and complain if it weren't).

I'd definitely like to keep rpartition.  For example, splitting an HTTP 
url's hostname from its port should be done with rpartition, since you can 
have a 'username:password@' part before the host, and because the host can 
be a bracketed bracketed IPv6 host address with colons in it.


>Simplicity and elegence are two of the reasons that this is such
>an excellent proposal,

+1.



More information about the Python-Dev mailing list