Steve Holden wrote:
>> * I acknowledge that Python *code* is almost certainly going to be edited in
>> a
>> left-to-right text editor, because it's an English-based programming
>> language.
>> But the strings that string methods like partition() and rpartition() are
>> used
>> with are quite
Nick Coghlan wrote:
> Phillip J. Eby wrote:
>
>>At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote:
>>
>>>On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
>>>
>>>
I think I finally figured out where Raymond is coming from.
For Raymond, "head" is where he started processing -- for rpartition,
Phillip J. Eby wrote:
> At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote:
>> On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
>>
>>> I think I finally figured out where Raymond is coming from.
>>>
>>> For Raymond, "head" is where he started processing -- for rpartition,
>>> this is the .endswith part.
>
Raymond Hettinger wrote:
[...]
> That's fine with me. I accept there will always be someone who stands
> on their head [...]
You'd have to be some kind of contortionist to stand on your head.
willfully-misunderstanding-ly y'rs - steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Ho
At 02:08 AM 9/6/2006 +0100, David Hopwood wrote:
>Barry Warsaw wrote:
> > The bias with these terms is clearly the English left-to-right
> > order. Actually, that brings up an interesting question: what would
> > happen if you called rpartition on a unicode string representing
> > Hebrew, Arabic,
Barry Warsaw wrote:
> The bias with these terms is clearly the English left-to-right
> order. Actually, that brings up an interesting question: what would
> happen if you called rpartition on a unicode string representing
> Hebrew, Arabic, or other RTL language? Do partition and rpartition
See, for me, it's all about the results of the operation, not how the
results are (supposedly) used. The way I think about it is that I've
got some string and I'm looking for some split point within that
string. That split point is clearly the "middle" (but "sep" works
too) and every
At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote:
>On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
>
> > I think I finally figured out where Raymond is coming from.
> >
> > For Raymond, "head" is where he started processing -- for rpartition,
> > this is the .endswith part.
> >
> > For me, "head" is th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
> I think I finally figured out where Raymond is coming from.
>
> For Raymond, "head" is where he started processing -- for rpartition,
> this is the .endswith part.
>
> For me, "head" is the start of the
I think I finally figured out where Raymond is coming from.
For Raymond, "head" is where he started processing -- for rpartition,
this is the .endswith part.
For me, "head" is the start of the data structure -- always the
.startswith part.
We won't resolve that with anything suggesting a sequent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 4:13 PM, Raymond Hettinger wrote:
> Tim Peters wrote:
>
>>upto, sep, rest
>>
>> in whatever order they apply.
>>
> In the rpartition case, that would be (rest, sep, upto) which seems a
> bit cryptic.
>
> We need some choice of w
Tim Peters wrote:
>upto, sep, rest
>
>in whatever order they apply.
>
In the rpartition case, that would be (rest, sep, upto) which seems a
bit cryptic.
We need some choice of words that clearly mean:
* the chopped-off snippet (guaranteed to not contain the separator)
* the separator if f
On 9/5/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> upto, sep, rest
>
> in whatever order they apply. I think of a partition-like function as
> starting at some position and matching "up to" the first occurence of
> the separator (be that left or right or diagonally, "up to" is
> relative to th
upto, sep, rest
in whatever order they apply. I think of a partition-like function as
starting at some position and matching "up to" the first occurence of
the separator (be that left or right or diagonally, "up to" is
relative to the search direction), and leaving "the rest" alone. The
docs
Ron Adam wrote:
>I hope this discussion is only about the words used and the
>documentation and not about the actual order of what is received. I
>would expect both the following should be true, and it is the current
>behavior.
>
> ''.join(s.partition(sep)) -> s
> ''.join(s.rpartition(sep)
Raymond Hettinger wrote:
> Another thought is that strings don't really have a left and right.
> They have a beginning and end. The left/right or top/bottom distinction
> is culture specific.
Well, it should have been epartition() and not rpartition() in that case. ;-)
Is python ever edite
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 2:32 PM, Raymond Hettinger wrote:
> Another thought is that strings don't really have a left and right.
> They have a beginning and end. The left/right or top/bottom
> distinction
> is culture specific.
For the target of the met
Ron Adam wrote:
Correcting myself...
> I hope this discussion is only about the words used and the
> documentation and not about the actual order of what is received. I
> would expect both the following should be true, and it is the current
> behavior.
>
> ''.join(s.partition(sep)) -> s
>
Michael Chermside wrote:
> Jim Jewett writes:
>> This change [in docs] looks wrong:
>>
>> PyDoc_STRVAR(rpartition__doc__,
>> -"S.rpartition(sep) -> (head, sep, tail)\n\
>> +"S.rpartition(sep) -> (tail, sep, head)\n\
>
> Raymond Hettinger replies:
>> It is correct. There may be some confusion in t
Jim Jewett wrote:
>
> Another possibility is data (for head/tail) and unparsed (for rest).
>
>S.partition(sep) -> (data, sep, unparsed)
>S.rpartition(sep) -> (unparsed, sep, data)
This communicates very little about the ordering of the return tuple.
Beware of overly general terms like
On 9/5/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sep 5, 2006, at 2:06 PM, Raymond Hettinger wrote:
>
> >> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
> >
> > Gads, the cure is worse than the disease.
> >
> > car and
On Tue, 5 Sep 2006, Fred L. Drake, Jr. wrote:
> On Tuesday 05 September 2006 13:24, Michael Chermside wrote:
> > How about something like this:
> >
> > S.partition(sep) -> (head, sep, tail)
> > S.rpartition(sep) -> (tail, sep, rest)
>
> I think I prefer:
>
>S.partition(sep) -> (head, s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 2:06 PM, Raymond Hettinger wrote:
>> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
>
> Gads, the cure is worse than the disease.
>
> car and cdr are starting to look pretty good ;-)
LOL, the lisper in me likes
On Tuesday 05 September 2006 14:02, Jim Jewett wrote:
> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
Whichever matches reality, sure. I've lost track of the rpartition() result
order. --sigh--
> Another possibility is data (for head/tail) and unparsed (for rest).
>
>
>
> Then shouldn't rpartition be S.rpartition(sep) -> (rest, sep, tail)
Gads, the cure is worse than the disease.
car and cdr are starting to look pretty good ;-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
On 9/5/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> S.partition(sep) -> (head, sep, rest)
> S.rpartition(sep) -> (tail, sep, rest)
> Here, "rest" is always used for "what remains"; head/tail are somewhat more
> clear here I think.
Then shouldn't rpartition be S.rpartition(sep) ->
On Tuesday 05 September 2006 13:46, Raymond Hettinger wrote:
> Changing to left/sep/right will certainly disambiguate questions about
left/right is definately not helpful. It's also ambiguous in the case
of .rpartition(), where left and right in the input and result are different.
> the order
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 1:46 PM, Raymond Hettinger wrote:
>> ISTM this is just begging for newbie (and maybe not-so-newbie)
>> confusion. Why not just document both as returning (left, sep,
>> right) which seems the most obvious description of what
On Tuesday 05 September 2006 13:24, Michael Chermside wrote:
> How about something like this:
>
> S.partition(sep) -> (head, sep, tail)
> S.rpartition(sep) -> (tail, sep, rest)
I think I prefer:
S.partition(sep) -> (head, sep, rest)
S.rpartition(sep) -> (tail, sep, rest)
Here
> ISTM this is just begging for newbie (and maybe not-so-newbie)
> confusion. Why not just document both as returning (left, sep,
> right) which seems the most obvious description of what the methods
> return?
I'm fine with that (though it's a little sad that we think the rather
basic co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2006, at 1:10 PM, Raymond Hettinger wrote:
>> This change looks wrong:
>>
>> PyDoc_STRVAR(rpartition__doc__,
>> -"S.rpartition(sep) -> (head, sep, tail)\n\
>> +"S.rpartition(sep) -> (tail, sep, head)\n\
>>
>> It looks like the code itself do
Jim Jewett writes:
> This change [in docs] looks wrong:
>
> PyDoc_STRVAR(rpartition__doc__,
> -"S.rpartition(sep) -> (head, sep, tail)\n\
> +"S.rpartition(sep) -> (tail, sep, head)\n\
Raymond Hettinger replies:
> It is correct. There may be some confusion in terminology. Head
> and tail do not
>
> This change looks wrong:
>
> PyDoc_STRVAR(rpartition__doc__,
> -"S.rpartition(sep) -> (head, sep, tail)\n\
> +"S.rpartition(sep) -> (tail, sep, head)\n\
>
> It looks like the code itself does the right thing, but I wasn't quite
> confident of that.
>
It is correct. There may be some confusion
> Jim Jewett wrote:
> >Why not just change which of the three strings holds the remainder in
> >the not-found case?
On 9/5/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> That was the only change submitted.
> Are you happy with what was checked-in?
This change looks wrong:
PyDoc_STRVAR(rpart
Jim Jewett wrote:
>
>Why not just change which of the three strings holds the remainder in
>the not-found case?
>
>
That was the only change submitted.
Are you happy with what was checked-in?
Raymond
___
Python-Dev mailing list
Python-Dev@python.o
35 matches
Mail list logo
