I think you're getting to implementation details here. Whether a new
string is returned or a reference to the old one is an optimization
decision. I don't think it's worth legislating this behavior one way
or another (especially since it's mostly a theoretical issue).
--Guido
On 5/26/06, Walter D
Guido van Rossum wrote:
> On 5/26/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> [...]
>> And what happens if the separator is an instance of a subclass?
>>
>> class s2(str):
>> def __repr__(self):
>> return "s2(%r)" % str(self)
>>
>> print "foobar".partition(s2("o"))
>>
>> Currently t
Raymond Hettinger wrote:
> 1) Is str.rpartition() still wanted?
>
> Yes.
I might have missed my earlier 30-minute deadline with one minute (not
my fault! I was distracted! seriously!), but this time, I actually
managed to get the code in there *before* I saw the pronouncement ;-)
_
> 1) Is str.rpartition() still wanted?
Yes.
___
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-archive.com
On 5/26/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> A.M. Kuchling wrote:
>
> > I didn't find an answer in the str.partition() thread in the archives
> > (it's enormous, so easy to miss the right message), so I have two
> > questions:
> >
> > 1) Is str.rpartition() still wanted?
Can't remember.
A.M. Kuchling wrote:
> I didn't find an answer in the str.partition() thread in the archives
> (it's enormous, so easy to miss the right message), so I have two
> questions:
>
> 1) Is str.rpartition() still wanted?
>
> 2) What about adding partition() to the re module?
And what happens if the s
Raymond Hettinger wrote:
>> I think it's convenient but also rather odd that split() with a static
>> string argument was moved from module string to a method in class str,
>> while split() with a regexp has remained in module re.
>
> I don't see what you find odd. With str and unicode objects bei
Nick Coghlan wrote:
> Ron Adam wrote:
>
>>I don't feel there is a need to avoid numbers entirely. In this case I
>>think it's the better way to find the n'th seperator and since it's an
>>optional value I feel it doesn't add a lot of complication. Anyway...
>>It's just a suggestion.
>
>
> Avoid
Le mardi 30 août 2005 à 12:29 -0500, [EMAIL PROTECTED] a écrit :
> Just group your re:
>
> >>> import re
> >>>
> >>> re.split("ab", "abracadabra")
> ['', 'racad', 'ra']
> >>> re.split("(ab)", "abracadabra")
> ['', 'ab', 'racad', 'ab', 'ra']
>
> and you get it in the retur
Ron Adam wrote:
> I don't feel there is a need to avoid numbers entirely. In this case I
> think it's the better way to find the n'th seperator and since it's an
> optional value I feel it doesn't add a lot of complication. Anyway...
> It's just a suggestion.
Avoid overengineering this without ge
Josiah Carlson a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
>
> 0.5
>
> So, subtracting that .5 seconds from all the cases gives us...
>
> 0.343 seconds for .find's comparison
> 0.313 seconds for .index's exception handling when an exception is not
> raised
> 3.797 seconds fo
Nick Coghlan wrote:
> Another option would be simply "str.part()" and "str.rpart()". Then you could
> think of it as an abbreviation of either 'partition' or 'parts' depending on
> your inclination.
Or simply as the verb 'part', which also makes sense!
Also it's short and snappy, whereas 'part
JustFillBug wrote:
> trisplit()
And then for when you need to record the result
somewhere, tricord(). :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
At 07:54 PM 8/30/2005 +0200, Fredrik Lundh wrote:
>Phillip J. Eby wrote:
>
> >>both split on a given token. partition splits once, and returns all three
> >>parts, while piece returns the part you ask for
> >
> > No, because looking at that URL, there is no piece that is the token split
> > on. p
Phillip J. Eby wrote:
> At 02:25 PM 8/30/2005 -0400, Raymond Hettinger wrote:
>
>> That case should be handled with consecutive partitions:
>>
>> # keep everything after the second 'X'
>> head, found, s = s.partition('X')
>> head, found, s = s.partition('x')
I was thinking of cases where head is
Phillip J. Eby wrote:
>>both split on a given token. partition splits once, and returns all three
>>parts, while piece returns the part you ask for
>
> No, because looking at that URL, there is no piece that is the token split
> on. partition() always returns 3 parts for 1 occurrence of the toke
Michael Hoffman wrote:
> Dare I ask whether the uncompiled versions should be considered for
> removal in Python 3.0?
>
> *puts on his asbestos jacket*
there are no uncompiled versions, so that's not a problem.
if you mean the function level api, it's there for convenience. if you're
using less
At 02:25 PM 8/30/2005 -0400, Raymond Hettinger wrote:
>That case should be handled with consecutive partitions:
>
># keep everything after the second 'X'
>head, found, s = s.partition('X')
>head, found, s = s.partition('x')
Or:
s=s.partition('X')[2].partition('X')[2]
which actually suggest
On 30 aug 2005, at 17:40, Antoine Pitrou wrote:
>> Neat!
>> +1 on regexps as an argument to partition().
>
> It sounds better to have a separate function and call it re.partition,
> doesn't it ?
> By the way, re.partition() is *really* useful compared to re.split()
> because with the latter you don
[Ron Adam]
> This would allow creating an iterator that could iterate though a
string
> splitting on each sep from either the left, or right.
For uses more complex than basic partitioning, people should shift to
more powerful tools like re.finditer(), re.findall(), and re.split().
> I can't thi
On Tue, 2005-08-30 at 12:39, Michael Chermside wrote:
> Michael Hoffman writes:
> > Dare I ask whether the uncompiled versions [of re object methods] should
> > be considered for removal in Python 3.0?
> No flames here, but I'd rather leave them. The docs make it clear that
> the two sets of funct
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> partition() works for me. It's not perfect, but it'll do. The idea
>> works for me rather more; it even simplifies the
>>
>> if s.startswith(prefix):
>> t = s[len(prefix):]
>> ...
>
> How would you do it? Something lik
>> Unrelated comment: maybe 'cut()' and rcut() would be nice short names.
Barry> FWIW, +1 on .cut(), +0 on .partition()
As long as people are free associating: snip(), excise(), explode(),
invade_iraq()...
Skip
___
Python-Dev mailing list
Py
>> http://docs.python.org/lib/re-objects.html
Michael> Dare I ask whether the uncompiled versions should be considered
Michael> for removal in Python 3.0?
It is quite convenient to not have to compile regular expressions in most
cases. The module takes care of compiling your pattern
Michael Chermside <[EMAIL PROTECTED]> wrote:
> 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.
Me too. I have var
On 30 aug 2005, at 17.11, Raymond Hettinger wrote:
> Hey guys, don't get lost in random naming suggestions (cut, snap,
> part,
> parts, yada yada yada). Each of those is much less descriptive and
> provides less differentiation from other string methods. Saving a few
> characters is not worth i
In fact, re.split with a grouped re is very much like Raymond's
str.partition method without the guarantee of returning a three-element
list.
Whoops... Should also have included the maxsplit=1 constraint.
Skip
___
Python-Dev mailing list
P
Antoine> By the way, re.partition() is *really* useful compared to
Antoine> re.split() because with the latter you don't which string
Antoine> precisely matched the pattern (it isn't an issue with
Antoine> str.split() since matching is exact).
Just group your re:
>>> import r
On Tue, 2005-08-30 at 11:27, Phillip J. Eby wrote:
> >So if partition() [or whatever it'll be called] could have an optional
> >second argument that defines the width of the 'cut' made, I would be
> >helped enormously. The default for this second argument would be
> >len(sep), to preserve the curr
Nick> I momentarily forgot that "part" is also a verb in its own right,
Nick> with the right meaning, too (think "parting your hair" and
Nick> "parting the Red Sea").
If I remember correctly from watching "The Ten Commandments" as a kid, I
believe Charlton Heston only parted the Red S
Raymond Hettinger wrote:
> [Delaney, Timothy (Tim)]
>
>>+1
>>
>>This is very useful behaviour IMO.
>
>
> Thanks. It seems to be getting +1s all around.
Wow, a lot of approvals! :)
>>Have the precise return values of partition() been defined?
+1 on the Name partition, I considered split or
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Well, what it does is exactly what I tought, you can express most of the
> use-cases of partition with:
>
> head, sep, tail = s.partition(sep)
> if not sep:
> #do something when it does not work
> else:
> #do something when it works
>
>
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, s
[Shane Hathaway writes about the existence of both module-level
functions and object methods to do the same regex operations]
> Apparently Python believes TMTOWTDI is the right practice here. ;-)
> See search, match, split, findall, finditer, sub, and subn:
>
> http://docs.python.org/lib/node114.h
Pierre Barbier de Reuille wrote:
>
> Shane Hathaway a écrit :
>>Are you sure? I would instead expect to find a .partition method on a
>>regexp object:
>>
>> head, sep, tail = re.compile(sep+'.'*offset).partition(some_str)
>
>
> Well, to be consistent with current re module, it would be better
Shane Hathaway a écrit :
> Eric Nieuwland wrote:
>
>> Pierre Barbier de Reuille wrote:
>>
>>> Or you want to have some "partition" method which accept regular
>>> expressions:
>>>
>>> head, sep, tail = some_str.partition(re.compile(sep+'.'*offset))
>>
>>
>>
>> Neat!
>> +1 on regexps as an argume
Eric Nieuwland wrote:
> Pierre Barbier de Reuille wrote:
>
>>Or you want to have some "partition" method which accept regular
>>expressions:
>>
>>head, sep, tail = some_str.partition(re.compile(sep+'.'*offset))
>
>
> Neat!
> +1 on regexps as an argument to partition().
Are you sure? I would in
> Neat!
> +1 on regexps as an argument to partition().
It sounds better to have a separate function and call it re.partition,
doesn't it ?
By the way, re.partition() is *really* useful compared to re.split()
because with the latter you don't which string precisely matched the
pattern (it isn't an
Pierre Barbier de Reuille wrote:
> Or you want to have some "partition" method which accept regular
> expressions:
>
> head, sep, tail = some_str.partition(re.compile(sep+'.'*offset))
Neat!
+1 on regexps as an argument to partition().
--eric
___
Python
I like partition() but maybe even better would be if strings supported
slicing by string indices.
key, sep, val = 'foo = 32'.partition('=')
would be:
key, val = 'foo = 32'[:'='], 'foo = 32'['=':]
To me it feels very natural to extend Python's slices to string
indices and would cover most of par
At 04:28 PM 8/30/2005 +0200, Eric Nieuwland wrote:
>I have some use cases with:
> cut_at = some_str.find(sep)
> head, tail = some_str[:cut_at], some_str[cut_at:]
>and:
> cut_at = some_str.find(sep)
> head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset !
At 10:01 AM 8/30/2005 +0200, Fredrik Lundh wrote:
>Phillip J. Eby wrote:
>
> >> Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See:
> >> http://www.jacquardsystems.com/Examples/function/piece.htm
> >
> > As far as I can see, either you misunderstand what partition() does, or
> > I'm
> > c
Hey guys, don't get lost in random naming suggestions (cut, snap, part,
parts, yada yada yada). Each of those is much less descriptive and
provides less differentiation from other string methods. Saving a few
characters is not worth introducing ambiguity.
Also, the longer name provides a useful
Nick> What about simply "str.parts" and "str.rparts"?
-1 because "parts" is not a verb. When I see an attribute that is a noun I
generally expect it to be a data attribute.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
Eric Nieuwland a écrit :
> I have some use cases with:
> cut_at = some_str.find(sep)
> head, tail = some_str[:cut_at], some_str[cut_at:]
> and:
> cut_at = some_str.find(sep)
> head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset !=
> len(sep)
>
> So if partit
Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Concerning names for partition(), I immediately thought of break().
> Unfortunately it's taken.
>
> So, how about snap()?
I like .part()/.rpart() (or failing that, .parts()/.rparts()). But if you
really want something short that's similar in meaning,
I have some use cases with:
cut_at = some_str.find(sep)
head, tail = some_str[:cut_at], some_str[cut_at:]
and:
cut_at = some_str.find(sep)
head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset !=
len(sep)
So if partition() [or whatever it'll be called]
Concerning names for partition(), I immediately thought of break().
Unfortunately it's taken.
So, how about snap()?
head, sep, tail = line.snap(':')
-j
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
(unlurking)
Le mardi 30 août 2005 à 23:20 +1000, Nick Coghlan a écrit :
> I momentarily forgot that "part" is also a verb in its own right, with the
> right meaning, too (think "parting your hair" and "parting the Red Sea").
"parts" sounds more obvious than the verb "part" which is little known
Nick Coghlan wrote:
> Another option would be simply "str.part()" and "str.rpart()". Then you could
> think of it as an abbreviation of either 'partition' or 'parts' depending on
> your inclination.
I momentarily forgot that "part" is also a verb in its own right, with the
right meaning, too (th
Delaney, Timothy (Tim) wrote:
> 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.
What about simply "str.parts" and "str.rparts"? That is, rather
Pierre Barbier de Reuille wrote:
> What I'm talking about is consistency. In most cases in Python, or at
> least AFAIU, error testing is avoided and exception launching is
> preferred mainly for efficiency reasons. So my question remains: why
> prefer for that specific method returning an "error" v
Michael Hudson wrote:
> partition() works for me. It's not perfect, but it'll do. The idea
> works for me rather more; it even simplifies the
>
> if s.startswith(prefix):
> t = s[len(prefix):]
> ...
How would you do it? Something like:
head, found, tail = s.partition(prefix)
if
Josiah Carlson a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
>
>>Well, I want to come back on a point that wasn't discussed. I only found
>>one positive comment here :
>>http://mail.python.org/pipermail/python-dev/2005-August/055775.html
>
>
> You apparently haven't been rea
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Well, I want to come back on a point that wasn't discussed. I only found
> one positive comment here :
> http://mail.python.org/pipermail/python-dev/2005-August/055775.html
You apparently haven't been reading python-dev for around 36 hours,
b
On 30/08/05, JustFillBug <[EMAIL PROTECTED]> wrote:
> 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 t
Well, I want to come back on a point that wasn't discussed. I only found
one positive comment here :
http://mail.python.org/pipermail/python-dev/2005-August/055775.html
It's about that :
Raymond Hettinger wrote:
> * The function always succeeds unless the separator argument is not a
> string type
Phillip J. Eby wrote:
>> Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See:
>> http://www.jacquardsystems.com/Examples/function/piece.htm
>
> 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 t
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> writes:
> 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 fa
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
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
73 matches
Mail list logo
