Andrew Durdin wrote:
> Just to put my spoke in the wheel, I find the difference in the
> ordering of return values for partition() and rpartition() confusing:
> head, sep, remainder = partition(s)
> remainder, sep, head = rpartition(s)
This is the confusion - you've got the terminology wrong.
before, sep, after = s.partition('?')
('http://www.python.org', '', '')
before, sep, after = s.rpartition('?')
('', '', 'http://www.python.org')
I once wrote a similar method called cleave(). My use case involved a
string-like class (Substr) whose instances could report their position in
the original string. The re module wasn't preserving
my class so I had to provide a different API.
def cleave(self, pattern, start=0):
"""return Substr until match, match, Substr after match
If there is no match, return Substr, None, ''
Here are some observations/questions on Raymond's partition() idea. First
of all, partition() is a much better name than cleave()!
Substr didn't copy as partition() will have to, won't many of uses of
partition() end up being
One way that gives the programmer a way avoid the copying would be to
provide a string method
findspan(). findspan() would returns the start and end of the found
position in the string. start >
end could signal no match; and since 0-character strings are disallowed in
partition, end == 0
could also signal no match. partition() could be defined in terms of
start, end = s.findspan(sep)
before, sep, after = s[:start], s[start:end], s[end:]
Just a quick thought,
Phillip J. Eby wrote:
> +1 for partition().
Looks like I'm getting seriously outvoted here ... Still, as I said I
don't think the name is overly important until the idea has been
accepted anyway. How long did we go with people in favour of "resource
manager" until "context manager" came up?
Of course, if I (or someone else) can't come up with an obviously better
name, partition() will win by default. I don't think it's a *bad* name -
just don't think it's a particularly *obvious* name.
I think that one of the things I have against it is that most times I
type it, I get a typo. If this function is accepted, I think it will
(and should!) become one of the most used string functions around. As
such, the name should be *very* easy to type.
Shane Hathaway wrote:
> Ron Adam wrote:
>> For cases where single values are desired, attribues could work.
>> line = line.partition(';').head
>> line = line.partition('#').head
>> But it gets awkward as soon as you want more than one.
>> sep, port = host.partition(':').head, host.partition(':').sep
> You can do both: make partition() return a sequence with attributes,
> similar to os.stat(). However, I would call the attributes "before",
> "sep", and "after".
I thought the same thing. I don't see a lot of use cases for it, but it
could be useful. I don't see how it could hurt.
Michael Hoffman writes:
> Dare I ask whether the uncompiled versions [of re object methods] should
> be considered for removal in Python 3.0?
> *puts on his asbestos jacket*
No flames here, but I'd rather leave them. The docs make it clear that
the two sets of functions/methods are equivalent, so the conceptual
overhead is small (at least it doesn't scale with the number of methods
in re). The docs make it clear that the compiled versions are faster, so
serious users should prefer them. But the uncompiled versions are
preferable in one special situation: short simple scripts -- the kind
of thing often done with shell scriping except that Python is Better (TM).
For these uses, performance is irrelevent and it turns a 2-line
construct into a single line.
Of course the uncompiled versions can be written as little 2-line
functions but that's even WORSE for short simple scripts.
Nearly everything I write these days is larger and more complex, but
I retain a soft spot for short simple scripts and want Python to
continue to be the best tool available for these tasks.
-- Michael Chermside
Raymond Hettinger wrote:
> Heh! Maybe AttributeError and NameError should be renamed to
> TypoError ;-) Afterall, the only time I get these exceptions is
> when the fingers press different buttons than the brain requested.
You misspelled TyopError ;)
Raymond Hettinger wrote:
> Yes, there is a precise spec and yes it always returns three strings.
> Movitation and spec:
Ah - thanks. Missed that in the mass of emails.
>> My major issue is with the names - partition() doesn't sound right to
> FWIW, I am VERY happy with the name partition(). It has a long and
> delightful history in conjunction with the quicksort algorithm where
> it does something very similar to what we're doing here:
I guessed that the motivation came from quicksort. My concern is that
"partition" is not something that most users would associate with
strings. I know I certainly wouldn't (at least, not immediately). The
behaviour is obvious from the name, but I don't feel the name is obvious
from the behaviour.
If I were explaining the behaviour of partition() to someone, the words
I would use are something like:
partition() splits a string into 3 parts - the bit before the
first occurrance of the separator, the separator, and the bit
after the separator. If the separator isn't in the string at
all then the entire string is returned as "the bit before" and
the returned separator and bit after are empty strings.
I'd probably also explain that if the separator is the very last thing
in the string the "bit after" would be an empty string, but that is
fairly intuitive in any case IMO.
It's a pity split() is already taken - but then, you would want split()
to do more in any case (specifically, split multiple times).
>> The discourse about Python3000 has shrunken from the expectation
>> of the "next big thing" into a depressive rhetorics of feature
>> elimination. The language doesn't seem to become deeper, smaller
>> and more powerfull but just smaller.
> There is much focus on removing things, because we want to be able
> to add new stuff but we don't want the language to grow.
ISTM that a major reason that the Python 3.0 discussion seems
focused more on removal than addition is that a lot of
addition can be (and is being) done in Python 2.x. This is a
huge benefit, of course, since people can start doing things
the "new and improved" way in 2.x, even though it's not until
3.0 that the "old and evil" ;) way is actually removed.
Removal of map/filter/reduce is an example - there isn't
discussion about addition of new features, because list
comps/gen expressions are already here...
> That suggests that we need a variant of split() that has been customized
> for typical find/index use cases. Perhaps introduce a new pair of
> methods, partition() and rpartition()
My only suggestion is that when you're about to make a truly
inspired suggestion like this one, that you use a new subject
header. It will make it easier for the Python-Dev summary
authors and for the people who look back in 20 years to ask
"That str.partition() function is really swiggy! It's everywhere
now, but I wonder what language had it first and who came up with
-- Michael Chermside
[PS: To explain what "swiggy" means I'd probably have to borrow
the time machine.]