On Wed, Mar 4, 2020 at 8:13 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> Sorry, I thought I was replying to something from today, not a year ago.
Which is fine — that conversation kind of petered out anyway, and I think
reviving it is a fine idea.
It sounds like you at least like the idea, so maybe it’s time to reframe
the conversation into “how should we do it” rather than “should we do it”.
Of course, in the end, a decision can’t be made without a specific
implementation, but it’s good to know if it’ll even be considered.
For my part, I prefer new methods over keyword parameters:
1) I don’t think any other string methods take keywords.
2) I believe Guido is credited with saying something like: it’s better to
write two functions than have one function that takes a keyword argument
that selects between two behaviors.
I wish I had the time/energy to spearhead this, but I honest don’t. But if
someone else does, I’d like to see it happen.
-CHB
My mail client decided that all old messages I didn’t read at the time were
> suddenly brand new additions to the thread, and I didn’t look at the dates.
> :)
>
> Sent from my iPhone
>
> > On Mar 4, 2020, at 19:21, Andrew Barnert via Python-ideas <
> python-ideas@python.org> wrote:
> >
> >
> >> On Mar 30, 2019, at 12:30, MRAB <pyt...@mrabarnett.plus.com> wrote:
> >>
> >> I'd much prefer .lcut/.rcut to .cut_prefix/.cut_suffix, to match
> .lstrip/.rstrip.
> >
> > I agree that we should use either l/r or something to do with start/end.
> We already have two different ways to say left/start and right/end on the
> str methods; adding a third way to say left/start/prefix seems silly.
> >
> > But I don’t like cut. Or trim, or any of the other options. They’re all
> just synonyms for strip; there’s nothing about any of these synonyms that
> tells you, implies, or even helps you remember that strip takes an iterable
> of characters and cut takes a substring (or is that a substring or tuple of
> substrings?) instead of the other way around.
> >
> > A name like lstrip_string would solve that.
> >
> > But so would modifying lstrip to take keyword arguments:
> >
> > s.lstrip("abc") # same as today
> > s.lstrip(chars="abc") # same as above
> > s.lstrip(string="abc") # the new functionality: only strip the whole
> thing
> >
> > Also, this means that if we do want the substring-or-substrings thing,
> we don’t have to use the old tuple idiom; since it’s a keyword-only param,
> we could just as easily have a different keyword param that accepts any
> iterable of strings. So when you have a set of prefixes, you don’t have to
> call s.lcut(tuple(prefixes)), you just pass the set as-is to
> s.lstrip(strings=prefixes)).
> >
> > _______________________________________________
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WKOFYDVTFE4FDKMSO5LQSY7QBQEMX2DV/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BXBL5Y7A43INP6XLUQUDFLLNGB47WEKP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PN3PL5CXRS3MTFTZAFIV7QDRWNR3G575/
Code of Conduct: http://python.org/psf/codeofconduct/
