Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
A bit of free thought brings me to the (half-baked) idea that if string
methods accepted any object which conformed to the buffer interface;
mmap, buffer, array, ... instances could gain all of the really
convenient methods
Charles Cazabon wrote:
also, a Boolean positional argument is a really poor clue about its meaning,
and it's easy to misremember the sense reversed.
I totally agree. I therefore borrowed the time machine and modified my
proposal to suggest it should be a keyword argument, not a positional
[Steve Holden]
The collective brainpower that's been exercised on this one
enhancement
already must be phenomenal, but the proposal still isn't perfect.
Sure it is :-)
It was never intended to replace all string parsing functions, existing
or contemplated. We still have str.index() so
On 9/1/05, Greg Ewing [EMAIL PROTECTED] wrote:
LD Gus Landis wrote:
.piece() can be both a verb and a noun
Er, pardon? I don't think I've ever heard 'piece' used
as a verb in English. Can you supply an example sentence?
- assemble: make by putting pieces together; She pieced a quilt
-
Ron Adam wrote:
I'm not familiar with piece, but it occurred to me it might be useful to
get attributes groups in some way. My first (passing) thought was to do...
host, port = host.partition(':').(head, sep)
Where that would be short calling a method to return them:
host, port
Raymond's original definition for partition() did NOT support any
of the following:
(*) Regular Expressions
(*) Ways to generate just 1 or 2 of the 3 values if some are
not going to be used
(*) Clever use of indices to avoid copying strings
(*) Behind-the-scenes tricks to allow
You can do both: make partition() return a sequence with attributes,
similar to os.stat(). However, I would call the attributes before,
sep, and after.
Terry One could see that as a special-case back-compatibility kludge
Terry that maybe should disappear in 3.0.
Back
At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote:
Raymond's original definition for partition() did NOT support any
of the following:
(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
(*) Ways to
Phillip J. Eby wrote:
Yep, subscripting and slicing are more than adequate to handle *all* of
those use cases, even the ones that some people have been jumping through
odd hoops to express:
before = x.partition(sep)[0]
found = x.partition(sep)[1]
after = x.partition(sep)[2]
Michael Chermside [EMAIL PROTECTED] wrote:
(*) An rpartition() function that searches from the right
...except that I understand why he included it and am convinced
by the arguments (use cases can be demonstrated and people would
expect it to be there and complain if it weren't).
I
On 8/31/05, Charles Cazabon [EMAIL PROTECTED] wrote:
I would think that perhaps an optional second argument to the method that
controls whether it searches from the start (default) or end of the string
might be nicer than having two separate methods, even though that would lose
parallelism
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
You can do both: make partition() return a sequence with
attributes,
similar to os.stat(). However, I would call the attributes
before,
sep, and after.
Terry One could see that as a special-case
Guido van Rossum [EMAIL PROTECTED] wrote:
On 8/31/05, Charles Cazabon [EMAIL PROTECTED] wrote:
While I'm at it, why not propose that for py3k that
.rfind/.rindex/.rjust/.rsplit disappear, and .find/.index/.just/.split
grow an optional fromright (or equivalent) optional keyword argument?
Michael Chermside wrote (but I reordered):
Simplicity and elegence are two of the reasons that this
is such an excellent proposal, let's not lose them.
Raymond's original definition for partition() did NOT support
any of the following:
(*) Regular Expressions
While this is obviously more
(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
Sounds right to me, and it *should* be orthogonally added to the 're'
module coincidentally simultaneously with the change to the string
object :-).
I have
Bill Janssen wrote:
(*) Regular Expressions
This can be orthogonally added to the 're' module, and definitely should
not be part of the string method.
Sounds right to me, and it *should* be orthogonally added to the 're'
module coincidentally simultaneously with the change to the
Fredrik Lundh wrote:
Phillip J. Eby wrote:
Yep, subscripting and slicing are more than adequate to handle *all* of
those use cases, even the ones that some people have been jumping through
odd hoops to express:
before = x.partition(sep)[0]
found = x.partition(sep)[1]
after =
Steve Holden [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
the problem isn't the time it takes to unpack the return value, the problem
is that
it takes time to create the substrings that you don't need.
Indeed, and therefore the performance of rpartition is likely to get
worse as
Fredrik Lundh wrote:
the problem isn't the time it takes to unpack the return value, the
problem is that it takes time to create the substrings that you don't
need.
I'm actually starting to think that this may be a good use case for
views of strings i.e. rather than create 3 new strings,
Hi,
FTR, I was not implying the $PIECE() was an answer at all, but only
suggesting it as an alternative name to .partition(). .piece() can be
both a verb and a noun as can .partition(), thus overcoming Nick's
objection to a nounish thing doing the work of a verbish thing.
Also, IIRC, I did say
for some use cases, a naive partition-based solution is going to be a
lot slower
than the old find+slice approach, no matter how you slice, index, or
unpack the
return value.
The index+slice approach will still be available for such cases. I am sure
we will see relative speed versus
Josiah Carlson wrote:
A bit of free thought brings me to the (half-baked) idea that if string
methods accepted any object which conformed to the buffer interface;
mmap, buffer, array, ... instances could gain all of the really
convenient methods that make strings the objects to use in many
LD Gus Landis wrote:
.piece() can be both a verb and a noun
Er, pardon? I don't think I've ever heard 'piece' used
as a verb in English. Can you supply an example sentence?
(And no, Piece, man! doesn't count. :-)
Greg
___
Python-Dev mailing list
Greg Ewing wrote:
LD Gus Landis wrote:
.piece() can be both a verb and a noun
Er, pardon? I don't think I've ever heard 'piece' used
as a verb in English. Can you supply an example sentence?
After Java splintered in 20XX, diehard fans desperately pieced together
the remaining fragments.
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Er, pardon? I don't think I've ever heard 'piece' used as a
Greg verb in English. Can you supply an example sentence?
I'll let the reader piece it together.
More closely related, I've heard/seen piece out used for task
allocation (from
Raymond Hettinger wrote:
[Fredrik Lundh]
it is, however, a bit worrying that you end up ignoring one or more
of the values in about 50% of your examples...
It drops to about 25% when you skip the ones that don't care about the
found/not-found field:
! _, sep, port =
Benji York wrote:
Raymond Hettinger wrote:
[Fredrik Lundh]
it is, however, a bit worrying that you end up ignoring one or more
of the values in about 50% of your examples...
It drops to about 25% when you skip the ones that don't care about the
found/not-found field:
! _, sep, port =
Shane Hathaway wrote:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port =
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port = host.partition(':').head,
I once wrote a similar method called cleave(). My use case involved a
string-like class (Substr) whose instances could report their position in
the original string. The re module wasn't preserving
my class so I had to provide a different API.
def cleave(self, pattern, start=0):
return
[EMAIL PROTECTED] wrote:
Substr didn't copy as partition() will have to, won't many of uses of
partition() end up being O(N^2)?
Yes. But if you look at most cases provided for in the standard library,
that isn't an issue. In the case where it becomes an issue, it is
generally because a user
Actually no. When str.parition() doesn't find the separator, you get s,
'', ''.
Yours would produce '', '', s. On not found, you would need to use
start==end==len(s).
You're right. Nevermind, then.
I will say the same
thing that I've said at least three times already (with a bit of an
At 01:05 AM 8/31/2005 +0200, Fredrik Lundh wrote:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
Fredrik Lundh wrote:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port = host.partition(':').head,
Shane Hathaway [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
You can do both: make partition() return a sequence with attributes,
similar to os.stat(). However, I would call the attributes before,
sep, and after.
One could see that as a special-case back-compatibility kludge
Terry Reedy wrote:
Shane Hathaway [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
You can do both: make partition() return a sequence with attributes,
similar to os.stat(). However, I would call the attributes before,
sep, and after.
One could see that as a special-case
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
37 matches
Mail list logo
