[Python-ideas] New explicit methods to trim strings

[Paul Moore]

On Tue, 2 Apr 2019 at 23:58, Cameron Simpson <cs at cskk.id.au> wrote:
> I think I find "might find it useful" more compelling than many do. Let
> me explain.
>
> I think a _well_ _defined_ battery is worth including in the kit (str
> methods) because:
>
> - the operation is simple and well defined: people won't be confused by
>   its purpose, and when they want it there is a reliable debugged method
>   sitting there ready for use
>
> - variations on this get written _all the time_, and writing those
>   variations using the method is more readable and more reliable
>
> - the existing .strip battery is misused for this purpose by accident
>
> I have in the past found myself arguing for adding little tools like
> this in agile teams, and getting a lot of resistence. The resistence
> tended to take these forms:
>
> - YAGNI. While the tiny battery _can_ be written longhand, every time
>   that happens makes for needlessly verbose code, is an opportunity for
>   stupid bugs, and makes code whose purpose must be _deduced_ rather
>   than doing what it says on the tin
>
> - not in this ticket: this leads to a starvation issue - the battery
>   never goes in with any ticket, and a ticket just for the battery never
>   gets chosen for a sprint
>
> - we've already got this other battery; subtext "not needed" or "we
>   don't want 2 ways to do this", my subtext "does it worse, or does
>   something which only _looks_ like this purpose". Classic example from
>   the codebase I was in at the time was SQL parameter insertion.
>   Eventually I said "... this" and wrote the battery anyway.

These are very good arguments, and they aren't something I'd really
thought about - they make a very good case (in general) for being
sympathetic to proposals for small features that "might be useful",
while also offering a couple of good tests for such proposals. "Simple
and well defined" in particular strikes me as important (and it's
often the one that gets lost when the bikeshedding about end cases
starts ;-))

> My position on cut*affix is that (a) it is easy to implement (b) it can
> thus be debugged once (c) it makes code clearer when used (d) it reduces
> the liklihood of .strip() misuse.

IMO, cut*fix at this point is mainly waiting on someone to actually
put a feature request on bpo, and an implementation PR on github. At
that point, whether it gets implemented will boil down to whether one
of the core devs likes it enough to merge. I doubt more discussion
here is going to make much difference, and the proposal isn't
significant enough to warrant a PEP.

Paul