Re: [Python-Dev] Proof of the pudding: str.partition()

2005-08-29 Thread Josiah Carlson
Raymond Hettinger [EMAIL PROTECTED] wrote: As promised, here is a full set of real-world comparative code transformations using str.partition(). The patch isn't intended to be applied; rather, it is here to test/demonstrate whether the new construct offers benefits under a variety of use

Re: [Python-Dev] Remove str.find in 3.0?

2005-08-29 Thread Michael Chermside
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,

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

2005-08-29 Thread Delaney, Timothy (Tim)
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

Re: [Python-Dev] Remove str.find in 3.0?

2005-08-29 Thread Tony Meyer
[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,

[Python-Dev] Alternative name for str.partition()

2005-08-29 Thread Greg Ewing
A more descriptive name than 'partition' would be 'split_at'. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

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

2005-08-29 Thread Raymond Hettinger
[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

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

2005-08-29 Thread Delaney, Timothy (Tim)
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

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

2005-08-29 Thread Anthony Baxter
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

Re: [Python-Dev] partition()

2005-08-29 Thread Stephen J. Turnbull
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

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

2005-08-29 Thread LD \Gus\ Landis
Hi, How about piece() ? Anthony can have his es 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 -

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

2005-08-29 Thread LD \Gus\ Landis
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 es that way too! ;-)

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

2005-08-29 Thread Fred L. Drake, Jr.
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. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org

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

2005-08-29 Thread Shane Hathaway
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,

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

2005-08-29 Thread Aahz
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

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

2005-08-29 Thread JustFillBug
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

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

2005-08-29 Thread Delaney, Timothy (Tim)
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