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
[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 peop
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 posit
Greg Ewing 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?
Main Entry: 2 piece
Function: transitive verb
Inflected Form(s): pieced; piec·ing
1 : to repair, renew, or complete by
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
> > convenien
> "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
all
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
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
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
>> 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 v
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 "noun"ish thing doing the work of a "verb"ish thing.
Also, IIRC, I did
Reinhold Birkenfeld writes:
> And it's horrible, for none of the other string methods accept a RE.
I suppose it depends on your perspective as to what exactly is
horrible. I tend to think it's too bad that none of the other string
methods accept appropriate RE patterns. Strings are thought of 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, e
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 ge
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]
>
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
> >(*) 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
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
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 keywor
<[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-
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
> paralleli
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).
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
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
>> 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
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
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:
>
> hos
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
"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-compatibilit
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.p
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
> 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
[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
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 Su
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, host.partiti
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, host.pa
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:
>>
>
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 = host.p
[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 = host.partition(':')
> > ! hea
Raymond Hettinger wrote:
> Overall, I found that partition() usefully encapsulated commonly
> occurring low-level programming patterns. In most cases, it completely
> eliminated the need for slicing and indices. In several cases, code was
> simplified dramatically; in some, the simplification wa
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
"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 u
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 cases.
Overall, I found that partition() usefully e
44 matches
Mail list logo
