[Python-Dev] Fwd: Problem withthe API for str.rpartition()

Steve Holden steve at holdenweb.com
Wed Sep 6 10:32:19 CEST 2006


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



More information about the Python-Dev mailing list