Re: [Python-Dev] Proof of the pudding: str.partition()
Raymond Hettinger wrote:
> Most patterns using str.find() directly translated into an equivalent
> using partition. The only awkwardness that arose was in cases where the
> original code had a test like, "if s.find(pat) > 0". That case
> translated to a double-term test, "if found and head".
That said, the latter would give me much greater confidence that the test for
"found, but not right at the start" was deliberate. With the original version
I would need to study the surrounding code to satisfy myself that it wasn't a
simple typo that resulted in '>' being written where '>=' was intended.
> With further ado, here are the comparative code fragments:
There's another one below that you previously tried rewriting to use str.index
that also benefits from str.partition. This rewrite makes it easier to avoid
the bug that afflicts the current code, and would make that bug raise an
exception if it wasn't fixed - "head[-1]" would raise IndexError if the head
was empty.
Cheers,
Nick.
--- From ConfigParser.py (current) ---
optname, vi, optval = mo.group('option', 'vi', 'value')
if vi in ('=', ':') and ';' in optval:
# ';' is a comment delimiter only if it follows
# a spacing character
pos = optval.find(';')
if pos != -1 and optval[pos-1].isspace():
optval = optval[:pos]
optval = optval.strip()
--- From ConfigParser.py (with str.partition) ---
optname, vi, optval = mo.group('option', 'vi', 'value')
if vi in ('=', ':'):
# ';' is a comment delimiter only if it follows
# a spacing character
head, found, _ = optval.partition(';')
if found and head and head[-1].isspace():
optval = head
optval = optval.strip()
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Doc/whatsnew whatsnew25.tex, 1.18, 1.19
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Doc/whatsnew
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29055
>
> Modified Files:
> whatsnew25.tex
> Log Message:
> Write section on PEP 342
>
> Index: whatsnew25.tex
> ===
> RCS file: /cvsroot/python/python/dist/src/Doc/whatsnew/whatsnew25.tex,v
> retrieving revision 1.18
> retrieving revision 1.19
> diff -u -d -r1.18 -r1.19
> --- whatsnew25.tex23 Aug 2005 00:56:06 - 1.18
> +++ whatsnew25.tex27 Aug 2005 18:45:47 - 1.19
> [snip]
> +\begin{verbatim}
> +>>> it = counter(10)
> +>>> print it.next()
> +0
> +>>> print it.next()
> +1
> +>>> print it.send(8)
> +8
> +>>> print it.next()
> +9
> +>>> print it.next()
> +Traceback (most recent call last):
> + File ``t.py'', line 15, in ?
> +print it.next()
> +StopIteration
>
> +Because \keyword{yield} will often be returning \constant{None},
> +you shouldn't just use its value in expressions unless you're sure
> +that only the \method{send()} method will be used.
This part creates a syntax error. \begin{verbatim} does not have its
end tag.
- george
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
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.] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] partition() (was: Remove str.find in 3.0?)
Michael Chermside wrote:
> 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?"
+1
This is very useful behaviour IMO.
Have the precise return values of partition() been defined?
Specifically, given:
'a'.split('b')
we could get back:
('a', '', '')
('a', None, None)
Similarly:
'ab'.split('b')
could be either:
('a', 'b', '')
('a', 'b', None)
IMO the most useful (and intuitive) behaviour is to return strings in
all cases.
My major issue is with the names - partition() doesn't sound right to
me. split() of course sounds best, but it has additional stuff we don't
necessarily want. However, I think we should aim to get the idea
accepted first, then work out the best name.
Tim Delaney
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
[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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Alternative name for str.partition()
A more descriptive name than 'partition' would be 'split_at'. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
[Delaney, Timothy (Tim)] > +1 > > This is very useful behaviour IMO. Thanks. It seems to be getting +1s all around. > Have the precise return values of partition() been defined? . . . > IMO the most useful (and intuitive) behaviour is to return strings in > all cases. 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 Pure python implementation, sample invocations, and tests: http://mail.python.org/pipermail/python-dev/2005-August/055764.html > 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: partitioning data into three groups (left,center,right) with a small center element (called a pivot in the quicksort context and called a separator in our string parsing context). This name has enjoyed great descriptive success in communicating that the total data size is unchanged and that the parts can be recombined to the whole. IOW, it is exactly the right word. I won't part with it easily. http://www.google.com/search?q=quicksort+partition Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: > > My major issue is with the names - partition() doesn't sound right to > > me. > > FWIW, I am VERY happy with the name partition(). I'm +1 on the functionality, and +1 on the name partition(). The only other name that comes to mind is 'separate()', but a) I always spell it 'seperate' (and I don't need another lamdba ) b) It's too similar in name to 'split()' Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition()
> "Raymond" == Raymond Hettinger <[EMAIL PROTECTED]> writes: Raymond> FWIW, I am VERY happy with the name partition(). Raymond> ... [I]t is exactly the right word. I won't part with it Raymond> easily. +1 I note that Emacs has a split-string function which does not have those happy properties. In particular it never preserves the separator, and (by default) it discards empty strings. Raymond> It has a long and delightful history in conjunction with Raymond> the quicksort algorithm Now, that is a delightful mnemonic! -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Hi, How about piece() ? Anthony can have his "e"s that way too! ;-) and it's the same number of characters as .split(). Cheers, --ldl On 8/29/05, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: > > > My major issue is with the names - partition() doesn't sound right to > > > me. > > > > FWIW, I am VERY happy with the name partition(). > > I'm +1 on the functionality, and +1 on the name partition(). The only other > name that comes to mind is 'separate()', but > a) I always spell it 'seperate' (and I don't need another lamdba ) > b) It's too similar in name to 'split()' > > Anthony > > -- > Anthony Baxter <[EMAIL PROTECTED]> > It's never too late to have a happy childhood. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com > -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Hi, Re: multiples, etc... Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See: http://www.jacquardsystems.com/Examples/function/piece.htm Cheers, --ldl On 8/29/05, LD Gus Landis <[EMAIL PROTECTED]> wrote: > Hi, > > How about piece() ? Anthony can have his "e"s that way too! ;-) > and it's the same number of characters as .split(). > > Cheers, > --ldl > -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: > FWIW, I am VERY happy with the name partition(). I like it too. +1 -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
At 10:33 PM 8/29/2005 -0500, LD \"Gus\" Landis wrote: >Hi, > > Re: multiples, etc... > > Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See: > http://www.jacquardsystems.com/Examples/function/piece.htm > >Cheers, > --ldl As far as I can see, either you misunderstand what partition() does, or I'm completely misunderstanding what $PIECE does. As far as I can tell, $PIECE and partition() have absolutely nothing in common except that they take strings as arguments. :) -1 on piece(), +1 for partition(). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Delaney, Timothy (Tim) wrote: > 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. FWIW, the analogy with quicksort convinced me that partition is a good name, even though I'm a terirlbe tpyist. I'm a pretty good proofreader, though. ;-) Shane ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On Tue, Aug 30, 2005, Delaney, Timothy (Tim) wrote: > > 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? In that case, though, it was more, "Well, I'm not that happy with 'context manager', but there doesn't seem to be anything better." This time, it's closer to, "That's a good name for the concept, yup." As you say, if someone comes up with a clearly better name, it likely will win; however, partition has been blessed by enough people that it's not worth putting much effort into finding anything better. > 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. It's at least as obvious as translate(). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [M.-A. Lemburg] >> Also, as I understand Terry's request, .find() should be removed >> in favor of just leaving .index() (which is the identical method >> without the funny -1 return code logic). My proposal is to use the 3.0 opportunity to improve the language in this particular area. I considered and ranked five alternatives more or less as follows. 1. Keep .index and delete .find. 2. Keep .index and repair .find to return None instead of -1. 3.5 Delete .index and repair .find. 3.5 Keep .index and .find as is. 5. Delete .index and keep .find as is. > It is new and separate, but it is also related. I see it as a 6th option: keep.index, delete .find, and replace with .partition. I rank this at least second and maybe first. It is separable in that the replacement can be done now, while the deletion has to wait. > The core of Terry's request is the assertion that str.find() > is bug-prone and should not be used. That and the redundancy, both of which bothered me a bit since I first learned the string module functions. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in > Yes, there is a precise spec and yes it always returns three strings. While the find/index discussion was about "what is the best way to indicate 'cannot answer'", part of the conclusion is that any way can be awkward. So I am generally in favor of defining a function, when possible, so that it can always deliver an answer (giving inputs of the appropriate types) and so that the 'best way' question is moot. Nicely done. I think the name 'partition' is fine too. It does not preclude putting a quicksort-type partition function in a module of list functions. The only alternative I can think of is 'tripart', but I do *not* prefer that. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On 2005-08-30, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: >> > My major issue is with the names - partition() doesn't sound right to >> > me. >> >> FWIW, I am VERY happy with the name partition(). > > I'm +1 on the functionality, and +1 on the name partition(). The only other > name that comes to mind is 'separate()', but > a) I always spell it 'seperate' (and I don't need another lamdba ) > b) It's too similar in name to 'split()' > trisplit() ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
