[Python-ideas] New explicit methods to trim strings

Cameron Simpson cs at cskk.id.au
Sun Mar 31 17:47:10 EDT 2019


On 31Mar2019 19:35, Steven D'Aprano <steve at pearwood.info> wrote:
>On Sun, Mar 31, 2019 at 04:48:36PM +1100, Chris Angelico wrote:
>> Regardless of the method name, IMO the functions should accept a 
>> tuple of test strings, as startswith/endwith do.

I did not know that!

>> That's a feature that can't
>> easily be spelled in a one-liner. (Though stacked suffixes shouldn't
>> all be removed - "asdf.jpg.png".cutsuffix((".jpg", ".png")) should
>> return "asdf.jpg", not "asdf".)
>
>There's a slight problem with that: what happens if more than one suffix
>matches? E.g. given:
>
>    "musical".lcut(('al', 'ical'))
>
>should the suffix "al" be removed, leaving "music"? (First match wins.)
>
>Or should the suffix "ical" be removed, leaving "mus"? (Longest match
>wins.)
>
>I don't think we can decide which is better, and I'm not keen on a
>keyword argument to choose one or the other, so I suggest we stick to
>the 90% solution of only supporting a single suffix.

This is easy to decide: first match wins. That is (a) simple and (b) 
very predictable for users.

You can easily get longest-match behaviour from this by sorting the 
suffixes. The reverse does not hold.

If anyone opposes my reasoning I can threaten them with my partner's 
story about Netscape proxy, where match rules rules were not processed 
in the order in the config file but by longest regexp pattern: yes, the 
longest regexp itself, nothing to do with what it matched. Config 
stupidity ensues.

Do things in the order supplied: that way the user has control. Doing 
things by length is imposing policy which can't be circumvented.

Cheers,
Cameron Simpson <cs at cskk.id.au>


More information about the Python-ideas mailing list