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 being
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 for .index's
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 return value. In fact, re.split
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
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 reading
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 value
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 than
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 (think
(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
to
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
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,
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 partition()
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
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
completely
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
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-Dev
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
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 instead expect to
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 argument to partition().
Are
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 to
follow
[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.html
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
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 parts, but i
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 current
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 re
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 patterns
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()...
wink
Skip
___
Python-Dev mailing list
[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 think
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't which
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 suggests a
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
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 token,
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. partition()
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
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 'partition'
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
[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
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
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
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 -
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! ;-)
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
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,
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
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
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
46 matches
Mail list logo
