Michael Chermside wrote (but I reordered):

Simplicity and elegence are two of the reasons that this is such an excellent proposal, let's not lose them.

Raymond's original definition for partition() did NOT support any of the following:

(*) Regular Expressions

While this is obviously more powerful, and an analogue should probably go in re ... it doesn't belong in strings. I don't want to have to explain why "www.python.org".part('.') acts strangely (forget to escape the period).

(*) Ways to generate just 1 or 2 of the 3 values if some are not going to be used (*) Clever use of indices to avoid copying strings (*) Behind-the-scenes tricks to allow repeated re-partitioning to be faster than O(n^2)

I think these may be useful behind the scenes, but the API should not expose them unless they are made more general. For instance, the compiler could recognize that junk variables (or variable names matching a certain pattern?) don't really have to be created -- and that would be useful for more than string splitting. Doing it as a special case here just leads to a backwards compatibility wart later. -jJ