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.
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/
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,
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
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
> 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
> i
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.o
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 actua
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 a
