Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.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. For me, head is the start of the data structure -- always the .startswith part. We won't resolve that with anything suggesting a sequential order; we need something that makes it clear which part is the large leftover. 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 everything to the right of that split point gets returned in right while everything to the left gets returned in left. +1 for left/sep/right for both operations. It's easier to remember a visual correlation (left,sep,right) than it is to try and think about an abstraction in which the order of results has something to do with what direction I found the separator in. -1. The string docs are already lousy with left/right terminology that is flatout wrong when dealing with a script that is displayed with a right-to-left or vertical orientation*. In reality, strings are processed such that index 0 is the first character and index -1 is the last character, regardless of script orientation, but you could be forgiven for not realising that after reading the current string docs. Let's not make that particular problem any worse. I don't see anything wrong with Raymond's 'head, sep, tail' and 'tail, sep, head' terminology (although noting the common postcondition 'sep not in head' in the docstrings might be useful). However, if we're going to use the same result tuple for both, then I'd prefer 'before, sep, after', with the partition() postcondition being 'sep not in before' and the rpartition() postcondition being 'sep not in after'. Those terms are accurate regardless of script orientation. Either way, I suggest putting the postcondition in the docstring to make the difference between the two methods explicit. Regards, Nick. * 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 likely to be coming from or written to a or user interface that uses a native script orientation. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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, 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 sequential order; we need something that makes it clear which part is the large leftover. 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 everything to the right of that split point gets returned in right while everything to the left gets returned in left. +1 for left/sep/right for both operations. It's easier to remember a visual correlation (left,sep,right) than it is to try and think about an abstraction in which the order of results has something to do with what direction I found the separator in. -1. The string docs are already lousy with left/right terminology that is flatout wrong when dealing with a script that is displayed with a right-to-left or vertical orientation*. In reality, strings are processed such that index 0 is the first character and index -1 is the last character, regardless of script orientation, but you could be forgiven for not realising that after reading the current string docs. Let's not make that particular problem any worse. I don't see anything wrong with Raymond's 'head, sep, tail' and 'tail, sep, head' terminology (although noting the common postcondition 'sep not in head' in the docstrings might be useful). However, if we're going to use the same result tuple for both, then I'd prefer 'before, sep, after', with the partition() postcondition being 'sep not in before' and the rpartition() postcondition being 'sep not in after'. Those terms are accurate regardless of script orientation. Either way, I suggest putting the postcondition in the docstring to make the difference between the two methods explicit. Regards, Nick. * 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 likely to be coming from or written to a or user interface that uses a native script orientation. Perhaps we should be thinking beginning and end here, though it seems as though it won't be possible to find a terminology that will be intuitively obvious to everyone. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 likely to be coming from or written to a or user interface that uses a native script orientation. Perhaps we should be thinking beginning and end here, though it seems as though it won't be possible to find a terminology that will be intuitively obvious to everyone. Which is why an example is absolutely necessary and will make things clear for everyone. Georg ___ 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
[Python-Dev] Fwd: Problem withthe API for str.rpartition()
Reversing the order of the return tuple will break the alignment with
split/rsplit.
Why not just change which of the three strings holds the remainder in
the not-found case?
In rc1,
d.rpartition(.) -- ('d', '', '')
If that changes to
d.rpartition(.) -- ('', '', 'd')
then
(1) the loop will terminate
(2) rpartition will be more parallel to partition (and split),
(3) people who used rpartition without looping to termination (and
therefore didn't catch the problem) will still be able to use their
existing working code.
(4) the existing docstring would remain correct, though it could
still be improved. (It says returns S and two empty strings, but
doesn't specify the order.)
-jJ
___
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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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(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. -jJ ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 in terminology. Head and tail do not mean left-side or right-side. Instead, they refer to the small part chopped-off and the rest that is still choppable. Think of head and tail in the sense of car and cdr. A post-condition invariant for both str.partition() and str.rpartition() is: assert sep not in head For non-looping cases, users will likely to use different variable names when they unpack the tuple: left, middle, right = s.rpartition(p) But when they perform multiple partitions, the tail or rest terminology is more appropriate for the part of the string that may still contain separators. Raymond ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 mean left-side or right-side. Instead, they refer to the small part chopped-off and the rest that is still choppable. Think of head and tail in the sense of car and cdr. It is incorrect. The purpose of documentation is to explain things to users, and documentation which fails to achieve this is not correct. The level of confusion generated by using head to refer to the last part of the string and tail to refer to the beginning, is quite significant. How about something like this: S.partition(sep) - (head, sep, tail) S.rpartition(sep) - (tail, sep, rest) Perhaps someone else can find something clearer than my suggestion, but in my own head, the terms head and tail are tighly bound with the idea of beginning and end (respectively) rather than with the idea of small part chopped off and big part that is still choppable. -- Michael Chermside ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
-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 does the right thing, but I wasn't quite confident of that. It is correct. There may be some confusion in terminology. Head and tail do not mean left-side or right-side. Instead, they refer to the small part chopped-off and the rest that is still choppable. Think of head and tail in the sense of car and cdr. A post-condition invariant for both str.partition() and str.rpartition() is: assert sep not in head For non-looping cases, users will likely to use different variable names when they unpack the tuple: left, middle, right = s.rpartition(p) But when they perform multiple partitions, the tail or rest terminology is more appropriate for the part of the string that may still contain separators. 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? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP2zPHEjvBPtnXfVAQKpvQP/X1Vg9G4gZLl9R7/fnevmfeszTbqVk1Bq V7aXYm5pTFiD27cKV2e7MKZPifob6Pg8NPjsvAh6jZU5Uj0BUQhIwgDXZpcivsTM MykyPz8oVpSLRhu5xfYU1IZjbogoKfPQ04FkqWgtM2QUqKjiLcvwzPnzLNLVxx9r v2LplvrqJyc= =Tckf -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 concepts of head and tail are beyond the grasp of typical pythonistas). Changing to left/sep/right will certainly disambiguate questions about the ordering of the return tuple. OTOH, there is some small loss in that the head/tail terminology is highly suggestive of how to use the function when making succesive partitions. Raymond ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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, rest is always used for what remains; head/tail are somewhat more clear here I think. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
-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 the methods return? I'm fine with that (though it's a little sad that we think the rather basic concepts of head and tail are beyond the grasp of typical pythonistas). Changing to left/sep/right will certainly disambiguate questions about the ordering of the return tuple. OTOH, there is some small loss in that the head/tail terminology is highly suggestive of how to use the function when making succesive partitions. Personally, I'd rather the docstring be clear and concise rather than suggestive of use cases. IMO, the latter would be better served as an example in the latex documentation. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP25cXEjvBPtnXfVAQJ4EwQAuKnVxtyabdtAv/Eu9CcZ8EkcwCJYOoAT DmgMWeml861Sn4qN6NV1vMKbXljxiKqoSBgbKdpU+FRb6TeNiCisuWA0Q9xoOfsj Jyvy3XN54WXCUBNBnfsfUROPqxjiNGnKxYUzx2a+pjkeSSSZxDzbuplU+2ijB6w4 HJWIT4JLldA= =u6iU -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 ordering of the return tuple. OTOH, there is some small loss in that the head/tail terminology is highly suggestive of how to use the function when making succesive partitions. See my previous note in this thread for another suggestion. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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) - (rest, sep, tail) Another possibility is data (for head/tail) and unparsed (for rest). S.partition(sep) - (data, sep, unparsed) S.rpartition(sep) - (unparsed, sep, data) I'm not sure which is worse -- (1) distinguishing between tail and rest (2) using (overly generic) jargon like unparsed and data. Whatever the final decision, it would probably be best to add an example to the docstring. a.b.c.rpartition(.) - (a.b, ., c) -jJ ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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). S.partition(sep) - (data, sep, unparsed) S.rpartition(sep) - (unparsed, sep, data) It's all data, so I think that's too contrived. I'm not sure which is worse -- (1) distinguishing between tail and rest (2) using (overly generic) jargon like unparsed and data. I don't see the distinction between tail and rest as problematic. But I've not used lisp for a long time. Whatever the final decision, it would probably be best to add an example to the docstring. a.b.c.rpartition(.) - (a.b, ., c) Agreed. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
-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 that too, but I don't think it'll work. :) Fred's disagreement notwithstanding, I still like (left, sep, right), but another alternative comes to mind after actually reading the docstring for rpartition wink: (before, sep, after). Now, that's not ambiguous is it? Seems to work for both partition and rpartition. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP2+AHEjvBPtnXfVAQLiPAP+N80jHkoT5VNTtX1h2cqD4pONz+j2maCI QXDBoODucxLDPrig8FJ3c6IcT+Uapifu8Rrvd7Vm8gSPMUsMqAgAqhqNDbXTkHVH xLk31en2k2fdiCQKQyKJSjE1R1CaFCezByV29FK3fWvqrrxObISRnsxf/wXB6Czu pOUNSA9LLKo= =g+iz -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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, 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. But isn't rest is in the wrong place there, for rpartition: that's not the string that you might typically call.rpartition() on a second time. How about: S.partition(sep) - (left, sep, rest) S.rpartition(sep) - (rest, sep, right) John ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 cdr are starting to look pretty good ;-) LOL, the lisper in me likes that too, but I don't think it'll work. :) but when it comes to cadr, cddr, cdar... ;^) I personally prefer (left, sep, right ) since it's most clear and there are many Python programmers whose first language is not English. Fred's disagreement notwithstanding, I still like (left, sep, right), but another alternative comes to mind after actually reading the docstring for rpartition wink: (before, sep, after). Now, that's not ambiguous is it? Seems to work for both partition and rpartition. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP2+AHEjvBPtnXfVAQLiPAP+N80jHkoT5VNTtX1h2cqD4pONz+j2maCI QXDBoODucxLDPrig8FJ3c6IcT+Uapifu8Rrvd7Vm8gSPMUsMqAgAqhqNDbXTkHVH xLk31en2k2fdiCQKQyKJSjE1R1CaFCezByV29FK3fWvqrrxObISRnsxf/wXB6Czu pOUNSA9LLKo= =g+iz -END PGP SIGNATURE- ___ 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/seojiwon%40gmail.com ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 data that provide no hints about
the semantics of the method.
The one good part that the terms are consistent between partition and
rpartition so that the invariant can be stated:
assert sep not in datum
I recommend we just leave the existing head/tail wording and add an
example which will make the meaning instantly clear:
'www.python.org'.rpartition('.')-- ('www.python', '.', 'org')
Also, remember that this discussion is being held in abstract. An
actual user of rpartition() is already thinking in terms of parsing from
the end of the string.
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.
Raymond
BTW, if someone chops your ankles, does it matter which way you're
facing to decide whether it was your feet or your head that had been
cut-off?
___
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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 terminology. Head
and tail do not mean left-side or right-side. Instead, they refer to
the small part chopped-off and the rest that is still choppable.
Think of head and tail in the sense of car and cdr.
It is incorrect. The purpose of documentation is to explain
things to users, and documentation which fails to achieve this
is not correct. The level of confusion generated by using head
to refer to the last part of the string and tail to refer to
the beginning, is quite significant.
How about something like this:
S.partition(sep) - (head, sep, tail)
S.rpartition(sep) - (tail, sep, rest)
This isn't immediately clear to me what I will get.
s.partition(sep) - (left, sep, right)
s.rpartition(sep) - (left, sep, right)
Would be clearer, along with an explanation of what left, and right are.
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)) - s
Perhaps someone else can find something clearer than my suggestion,
but in my own head, the terms head and tail are tighly bound
with the idea of beginning and end (respectively) rather than with
the idea of small part chopped off and big part that is still
choppable.
Maybe this?
partition(...)
S.partition(sep) - (left, sep, right)
Partition a string at the first occurrence of sep from the
left into a tuple of left, sep, and right parts.
Returns (S, '', '') if sep is not found in S.
rpartition(...)
S.rpartition(sep) - (left, sep, right)
Partition a string at the first occurrence of sep from the right
into a tuple of left, sep, and right parts.
Returns ('', '', S) if sep is not found in S.
I feel the terms head and tail, rest etc... should be used in examples
where their meaning will be clear by the context they are used in. But
not in the definition where their meanings are not obvious.
Cheers,
Ron
___
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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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
''.join(s.rpartition(sep)) - s
'abcd'.partition('x')
('abcd', '', '')
'abcd'.rpartition('x')
('abcd', '', '')
Ok, I see Raymonds point, they are not what I expected.
Although the above is still true, the returned value for the not found condition
is inconsistent.
_Ron
___
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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
-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 method, this is true, but it's not true for the results which is what we're talking about describing here. 'left' is whatever is to the left of the separator and 'right' is whatever is to the right of the separator. Seems obvious to me. I believe (left, sep, right) will be the clearest description for all users, with little chance of confusion. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP3HIXEjvBPtnXfVAQIx5wP+MPF5tk4moX4jH0yhGvR6gKcGBusyN152 redIr0xiNqECfrIHkc756UDLn3HhB2WdEjR9pn06RzmbgePMPcGP19cjZdHGwjFK 3e4Qg8zW3cL0iCnybL4AEaoZksuHGwJpZbId9HF60GFqYdjNTKEMNIVRI7jTE9pP zbBO6Sscnl0= =HB4k -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 edited in languages that don't use left to right lines? ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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)) - s
Right. The only thing in question is wording for the documentation.
The viable options on the table are:
* Leave the current wording and add a clarifying example.
* Switch to left/sep/right and add a clarifying example.
The former tells you which part can still contain a separator and
suggests how to use the tool when successive partitions are needed. The
latter makes the left/right ordering clear and tells you nothing about
which part can still have the separators in it. That has some import
because the use cases for rpartition() all involve strings with multiple
separators --if there were only one, you would just use partition().
BTW, the last check-in fixed the return value for the sep-not-found
case, so that now:
'a'.partition('x') -- ('a', '', '')
'a'.rpartition('x') -- ('', '', 'a')
This was necessary so that looping/recursion would work and so that
rpartition() acts as a mirror-image of partition().
Raymond
___
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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 should match that, since my mental model is correct ;-) ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 the search direction), and leaving the rest alone. The docs should match that, since my mental model is correct ;-) +1 Paul ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 found * the unchopped remainer of the string (which may contain a separator). Of course, if a clear example is added, the choice of words becomes much less important. Raymond ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
-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 words that clearly mean: * the chopped-off snippet (guaranteed to not contain the separator) * the separator if found * the unchopped remainer of the string (which may contain a separator). Of course, if a clear example is added, the choice of words becomes much less important. Ideally too, the terminology (and order) for partition and rpartition would be the same. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP3bVXEjvBPtnXfVAQJSKwP9Ev3MPzum3kp4hNDJZyBmEShzPvL2WQv2 VThbxZX1MDfeDXupNwF22bFA5gF/9vZp3nToUqyAbOaPSd93hJSHOdeWdAhR2BdT EICkzBTGCtVkbqu3Ep1N/jb9GJUvgkgNAWtRZVuTWQtJc6AanV9ssTcF6F7ipc6p zgSWeAc0a3E= =W7LV -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 sequential order; we need something that makes it clear which part is the large leftover. S.partition(sep) - (record, sep, remains) S.rpartition(sep) - (remains, sep, record) I do like the plural (or collective) sound of remains. I have no solid reasoning for record vs rec vs onerec. I would welcome a word that did not suggest it would have further internal structure. -jJ ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
-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 data structure -- always the .startswith part. We won't resolve that with anything suggesting a sequential order; we need something that makes it clear which part is the large leftover. 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 everything to the right of that split point gets returned in right while everything to the left gets returned in left. I'm less concerned with repeated splits because I probably have as many existing cases where I'm looking for the first split point as where I'm looking repeatedly for split points (think RFC 2822 header splitting -- partition will be awesome for this). 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 suddenly switch directions? If not, then I think left-sep-right are fine. If so, then yeah, we probably need something else. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRP3kUHEjvBPtnXfVAQJd6wP+OBtRR22O0A+s/uHF3ACgWhrdZJdEnzEW qimKEWmDCUuK7CFIUsJKteoNNSHjIBgZIMMdnsymgI7CPgPNuB6CUAp8KFFeYvMy PVpMIqNFOFXGUVYf4VA7ED9S7QbbDzHJv32kUUZvbuTniYK9DVMi0O7GStsv1Kg6 insyP+W1EcU= =4aar -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 the start of the data structure -- always the .startswith part. We won't resolve that with anything suggesting a sequential order; we need something that makes it clear which part is the large leftover. 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 everything to the right of that split point gets returned in right while everything to the left gets returned in left. +1 for left/sep/right for both operations. It's easier to remember a visual correlation (left,sep,right) than it is to try and think about an abstraction in which the order of results has something to do with what direction I found the separator in. If I'm repeating from right to left, then of course the left is the part I'll want to repeat on. ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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 suddenly switch directions? What happens is that rpartition searches the string backwards in logical order (i.e. left to right as the text is written, assuming it only contains Hebrew or Arabic letters, and not numbers or a mixture of scripts). But this is not switching directions; it's still searching backwards. You really don't want to think of bidirectional text in terms of presentation, when you're doing processing that should be independent of presentation. If not, then I think left-sep-right are fine. If so, then yeah, we probably need something else. +1 for (upto, sep, rest) -- and I think it should be in that order for both partition and rpartition. -- David Hopwood [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] Fwd: Problem withthe API for str.rpartition()
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, or other RTL language? Do partition and rpartition suddenly switch directions? What happens is that rpartition searches the string backwards in logical order (i.e. left to right as the text is written, assuming it only contains Hebrew or Arabic letters, and not numbers or a mixture of scripts). But this is not switching directions; it's still searching backwards. You really don't want to think of bidirectional text in terms of presentation, when you're doing processing that should be independent of presentation. If not, then I think left-sep-right are fine. If so, then yeah, we probably need something else. +1 for (upto, sep, rest) -- and I think it should be in that order for both partition and rpartition. It appears the problem is that one group of people thinks in terms of the order of the string, and the other in terms of the order of processing. Both groups agree that both partition and rpartition should be in the same order -- but we disagree about what that means. :) Me, I want left/sep/right because I'm in the string order camp, and you want upto/sep/rest because you're in the processing order camp. ___ 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
