[Python-Dev] partition() (was: Remove str.find in 3.0?)

Pierre Barbier de Reuille pierre.barbier at cirad.fr
Tue Aug 30 10:11:23 CEST 2005

Well, I want to come back on a point that wasn't discussed. I only found
one positive comment here :

It's about that :

Raymond Hettinger wrote:
> * The function always succeeds unless the separator argument is not a
> string type or is an empty string.  So, a typical call doesn't have to
> be wrapped in a try-suite for normal usage.

Well, I wonder if it's so good ! Almost all the use case I find would
require something like:

head, sep, tail = s.partition(t)
if sep:
   do something
   do something else

Like, if you want to extract the drive letter from a windows path :

drive, sep, tail = path.partition(":")
if not sep:
   drive = get_current_drive() # Because it's a local path

Or, if I want to iterate over all the path parts in a UNIX path:

sep = '/'
while sep:
  head, sep, path = path.partition(sep)

IMO, that read strange ... partitionning until sep is None :S
Then, testing with "if" in Python is always a lot slower than having an
exception launched from C extension inside a try...except block.

So both construct would read like already a lot of Python code:

  head,sep,tail = s.partition(t)
  do something
except SeparatorException:
  do something else


   while 1:
      head, drop, path = path.partition(sep)
except SeparatorException:
  The end

To me, the try..except block to test end or error conditions are just
part of Python design. So I don't understand why you don't want it !

For the separator, keeping it in the return values may be very useful,
mainly because I would really like to use this function replacing string
with a regexp (like a simplified version of the Qt method
QStringList::split) and, in that case, the separator would be the actual
matched separator string.


Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68

More information about the Python-Dev mailing list