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
__
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 o
"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 favo
"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
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
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,
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 c
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()
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
Python-Dev@python.org
http://mail.python.org/mailman/listinf
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! ;-)
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 -
> "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 ha
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
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
[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 precis
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:
http://mail.python.org/mailman/options/python-dev/archive%40mail-arch
[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 removi
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
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
[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
> ===
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".
Tha
21 matches
Mail list logo
