[Python-Dev] Re: strip behavior provides inconsistent results with certain strings
It seems to me that the desired behavior is closest to 'str.replace()' out
of all the options, just with the constraint of being limited to either the
start or the end of the string. (Thus the .lreplace() and .rreplace()
option suggested by Glenn earlier in the thread.)
The minimal change (which actually also seems pretty general) seems to me
to be adding *only_start* and *only_end* keyword arguments to
str.replace(), both defaulting to False. If, e.g., *only_start* is passed
True, each repetition of *old* at the start of *str* is replaced by a copy
of *new*, with the number of replacements limited by the existing optional
*count*. Similar behavior for *only_end*=True. Probably best to raise a
ValueError(?) if both *only_start*=True and *only_end*=True?
Taking swapping a file extension as an example of a particular
transformation of interest, it would be achieved with something like
s.replace(".htm", ".html", only_end=True).
-Brian
--
>
> Date: Tue, 2 Jul 2019 14:33:57 +1000
> From: Chris Angelico
> Subject: [Python-Dev] Re: strip behavior provides inconsistent results
> with certain strings
> To: python-dev
> Message-ID:
> x64_vdym9jaj0z9n19te7dk+navvoxoih7...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Jul 2, 2019 at 2:28 PM Glenn Linderman
> wrote:
> >
> >> A method could raise instead of returning the string as-is if the
> prefix is not really a prefix. How often is this needed? The most common
> end deletions are whitespace, which the current .strip handles correctly.
> >
> > raising wouldn't be helpful in most of the situations where I use this
> logic... it would require a more complex flow control than the if
> startswith path in the current situation.
> >
> > Yes, I use strip more frequently, but if startswith: chop_prefix
> operation (and the other end too) happens an awful lot.
>
> If the method accepts a tuple of prefixes and will remove the first
> one found (or the longest, or whatever) and raises if none found, you
> could get the "chop only if present" behaviour by including an empty
> string as one of the possible prefixes.
>
> ChrisA
>
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/SCZH4SYCM2Z2UXTKYMAIMHGRUKGKD2FU/
[Python-Dev] Re: strip behavior provides inconsistent results with certain strings
It seems to me that the desired behavior here is closest to 'str.replace()' out
of all the options discussed, just with the constraint of being limited to
either the start or the end of the string. (Thus the .lreplace() and
.rreplace() option suggested by Glenn.)
The minimal change (which actually also is pretty general?) I think would be to
add 'only_start' and 'only_end' keyword arguments to str.replace(), both
defaulting to False. If, e.g., 'only_start' is passed True, each repetition of
'old' at the start of 's' is replaced by 'new', with the number of replacements
limited by the existing optional 'count'. Similar behavior for 'only_end'=True.
Probably best to raise a ValueError(?) if both 'only_start'=True and
'only_end'=True?
Taking swapping a file extension as an example of a particular transformation
of interest, it would be achieved with something like s.replace(".htm",
".html", only_end=True).
-Brian
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/N3VNJHO467YT53ZVIAAGKEWOYISJ4VTY/
[Python-Dev] Re: What to do about invalid escape sequences
Steven D'Aprano wrote: > Because our processes don't work the way we assumed, it turns out that > in practice we haven't given developers the deprecation period we > thought we had. Read Nathaniel's post, if you haven't already done so: > https://mail.python.org/archives/list/python-dev@python.org/message/E7QCC74O... > He makes a compelling case that while we might have had the promised > deprecation period by the letter of the law, in practice most developers > will have never seen it, and we will be breaking the spirit of the > promise if we continue with the unmodified plan. > ... > I'm sure that the affected devs will understand why it was their fault > they couldn't see the warnings, when even people from a first-class > library like SymPy took four iterations to do it right. > > Currently it > > requires some extra steps or flags, which are not well known. What > > change are you proposing for 3.8 that will ensure that this actually > > gets solved? > > Absolutely nothing. I don't have to: we're an entire community, this > doesn't have to fall only on my shoulders. I'm not even the messenger: > that's Raymond. I'm just (partly) agreeing with him. > Just because I don't have a solution for this problem doesn't mean the > problem doesn't exist. As the SymPy team has figured out the right pytest incantation to expose these warnings, perhaps a feature request on pytest to encapsulate that mix of options into a single flag would be a good idea? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WOJQTOXMYKHLQO4KICEIZH3PDEMQLMBL/
[Python-Dev] Re: What to do about invalid escape sequences
> This whole thread would be an excellent justification for following 3.9 > with 4.0. It's as near as we ever want to get to a breaking change, and a > major version number would indicate the need to review. If increasing > strictness of escape code interpretation in string literals is the only > incompatibility there would surely be general delight. > > Kind regards, > Steve Holden I rather doubt that allowing breaking changes into a Python 4.0 would end up with this as the only proposed incompatibility. Once word got out, a flood of incompat requests would probably get raised. I personally have a change I'd like made to doctest (https://bugs.python.org/issue36714), and I know of another in argparse (https://bugs.python.org/issue33109) that I'm personally neutral on but that others have stronger feelings about. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SEBJF7C7RRG3Q3MFD5D6CTOFZUX7DNSE/
[Python-Dev] Re: What to do about invalid escape sequences
Eric V. Smith wrote: > Hopefully the warnings in 3.9 would be more visible that what we saw in > 3.7, so that library authors can take notice and do something about it > before 3.10 rolls around. > Eric Apologies for the ~double-post on the thread, but: the SymPy team has figured out the right pytest incantation to expose these warnings. Given the extensive adoption of pytest, perhaps it would be good to combine (1) a FR on pytest to add a convenience flag enabling this mix of options with (2) an aggressive "marketing push", encouraging library maintainers to add it to their testing/CI. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S2464WJ3QCDE4CBM6AWITHMFCISA6O75/
[Python-Dev] Re: What to do about invalid escape sequences
Nathaniel Smith wrote: > Unfortunately, their solution isn't a pytest incantation, it's a > separate 'compileall' invocation they run on their source tree. I'm > not sure how you'd convert this into a pytest feature, because I don't > think pytest always know which parts of your code are your code versus > which parts are supporting libraries. > -n Ahh, did not appreciate this. :-( Nevermind, then! ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VFFV7MJUZKMSD6FS3OONSEN5XLBOLT5R/
[Python-Dev] Re: Inline links in Misc/NEWS entries
Citing from the current (19 Aug 2019) version of this PR (https://github.com/python/devguide/pull/525/files#diff-50cb76bbe8ae3fcd4170dc6e8d9d6b3fR225-R226): > Before using any Sphinx roles, ensure that a corresponding entry exists > within the documentation. At the risk of crass self-promotion, the talk I gave last month at PyOhio (https://www.pyohio.org/2019/presentations/137) provides step-by-step instructions for how to find the information needed to craft a working Sphinx cross-reference, along with some of the tooling that's available. Right now I have the slides up as a view-only share in my Google Drive (bit.ly/bskinn-pyohio2019-intersphinx). Perhaps it would be useful to link to them? Or, to host a PDF someplace more permanent, and link to that? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IK5XP7CPZDF2FSFG55JRKXHEXNTOMUTB/
[Python-Dev] Re: The Python 2 death march
it's getting better? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C52ZRWV5XXYXS7VRDNH6I7IDIMO2A2PM/
[Python-Dev] Re: 3.10 or 4.0?
I've appreciated Anthony Sottile's flake8-2020 plugin (https://pypi.org/project/flake8-2020/), which adds checks for a variety of misuses of sys.version and sys.version_info that would lead to breakage on a Python 4.0, and/or 10.0, in addition to Python 3.10. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FHROEYFSPBWJQ2L7MX7I6G3NAG6WQBQJ/ Code of Conduct: http://python.org/psf/codeofconduct/
