Mailman 3 August 2005 - Python-Dev

Remove str.find in 3.0?
by Terry Reedy Aug. 31, 2005

Aug. 31, 2005

Can str.find be listed in PEP 3000 (under builtins) for removal? Would anyone really object? Reasons: 1. Str.find is essentially redundant with str.index. The only difference is that str.index Pythonically indicates 'not found' by raising an exception while str.find does the same by anomalously returning -1. As best as I can remember, this is common for Unix system calls but unique among Python builtin functions. Learning and remembering both is a nuisance. 2. As is being discussed in a current c.l.p thread, -1 is a legal indexing subscript. If one uses the return value as a subscript without checking, the bug is not caught. None would be a better return value should find not be deleted. 3. Anyone who prefers to test return values instead of catch exceptions can write (simplified, without start,end params): def sfind(string, target): try: return string.index(target) except ValueError: return None # or -1 for back compatibility, but None better This can of course be done for any function/method that indicates input errors with exceptions instead of a special return value. I see no reason other than history that this particular method should be doubled. If .find is scheduled for the dustbin of history, I would be willing to suggest doc and docstring changes. (str.index.__doc__ currently refers to str.find.__doc__. This should be reversed.) Terry J. Reedy

23 64

Re: [Python-Dev] Remove str.find in 3.0?
by Delaney, Timothy (Tim) Aug. 30, 2005

Aug. 30, 2005

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') Tim Delaney

6 6

Re: [Python-Dev] Proof of the pudding: str.partition()
by tony＠lownds.com Aug. 30, 2005

Aug. 30, 2005

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 O(N^2)? 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 findspan(): start, end = s.findspan(sep) before, sep, after = s[:start], s[start:end], s[end:] Just a quick thought, -Tony

2 2

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
by Delaney, Timothy (Tim) Aug. 30, 2005

Aug. 30, 2005

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. Tim Delaney

13 16

Re: [Python-Dev] Proof of the pudding: str.partition()
by Delaney, Timothy (Tim) Aug. 30, 2005

Aug. 30, 2005

Shane Hathaway wrote: > Ron Adam wrote: >> For cases where single values are desired, attribues could work. >> >> Slicing: >> 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". +0 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. Tim Delaney

1 0

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
by Michael Chermside Aug. 30, 2005

Aug. 30, 2005

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

3 2

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
by Delaney, Timothy (Tim) Aug. 29, 2005

Aug. 29, 2005

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 ;) Tim Delaney

1 0

Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
by Delaney, Timothy (Tim) Aug. 29, 2005

Aug. 29, 2005

Raymond Hettinger wrote: > Yes, there is a precise spec and yes it always returns three strings. > > Movitation and spec: > http://mail.python.org/pipermail/python-dev/2005-August/055764.html Ah - thanks. Missed that in the mass of emails. >> My major issue is with the names - partition() doesn't sound right to >> me. > > 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). Tim Delaney

1 0

Re: [Python-Dev] Remove str.find in 3.0?
by Tony Meyer Aug. 29, 2005

Aug. 29, 2005

[Kay Schluehr] >> 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. [Guido] > 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... =Tony.Meyer

1 0

Re: [Python-Dev] Remove str.find in 3.0?
by Michael Chermside Aug. 29, 2005

Aug. 29, 2005

Raymond writes: > 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() +1 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 it?" -- Michael Chermside [PS: To explain what "swiggy" means I'd probably have to borrow the time machine.]

1 0