[Python-Dev] Re: 3.10 change (?) for __bool__

On 1/13/2021 8:56 PM, Greg Ewing wrote: On 14/01/21 1:13 pm, Paul Sokolovsky wrote: But nobody talked about optimizing away generic "pure"-annotated functions (which would differ from "mathematical" definition of purity), only about optimizing "pure" *dunder* methods The same thing applies. If

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 1:13 pm, Paul Sokolovsky wrote: But nobody talked about optimizing away generic "pure"-annotated functions (which would differ from "mathematical" definition of purity), only about optimizing "pure" *dunder* methods The same thing applies. If we decide that print() is pure, then a _

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Thu, 14 Jan 2021 12:45:11 +1300 Greg Ewing wrote: > On 14/01/21 6:17 am, Paul Sokolovsky wrote: > > For > > example, print() would be considered "pure", as its purpose is to > > provide program output, not arbitrarily change program state > > That definition of purity wouldn't reall

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 6:17 am, Paul Sokolovsky wrote: For example, print() would be considered "pure", as its purpose is to provide program output, not arbitrarily change program state That definition of purity wouldn't really help with optimisations, though, because optimising away a print() call would

[Python-Dev] Re: 3.10 change (?) for __bool__

On 14/01/21 5:29 am, Steven D'Aprano wrote: No, I don't think it is possible to enforce lack of side-effects. Not without rebuilding the language from the ground up with a clear, definitive and enforcable distinction between pure and impure functions. (I think Haskell does something like that.

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On 1/13/21 8:24 PM, Brett Cannon wrote: On Wed, Jan 13, 2021 at 7:25 AM Serhiy Storchaka > wrote: 12.01.21 22:38, Julien Palard via Python-Dev пише: > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > Problem is Sphinx 3 have s

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

My take on this is to keep it simple for CPython: Require the newer version of Sphinx on all branches we backport docs changes to. We, the CPython project, determine the exact version(s) of Sphinx a documentation build for a given version of CPython requires. If Sphinx has unfortunately made a br

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On Wed, Jan 13, 2021 at 7:25 AM Serhiy Storchaka wrote: > 12.01.21 22:38, Julien Palard via Python-Dev пише: > > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > > > Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that > > we could work around, some are

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Thu, 14 Jan 2021 03:29:35 +1100 Steven D'Aprano wrote: > On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote: > > Even if you define __bool__() as returning a bool, and > > error/undefined behavior otherwise, that doesn't eliminate side > > effects. Is it even possible to nai

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote: > Even if you define __bool__() as returning a bool, and error/undefined > behavior otherwise, that doesn't eliminate side effects. Is it even > possible to nail down a definition to the point that you can say, "Thou > shalt not mutate

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 08:27:46PM +1100, Chris Angelico wrote: > It's a lot faster for C-implemented functions to require positional > parameters. A number of functions had help text that implied that they > accepted keyword-or-positional args, but if you tried to call them > with keyword args, t

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

Hi Julien, I think that there are two items to consider: - `needs_sphinx` in `conf.py` - setting for Sphinx in `cpython/Doc/requirements.txt` I believe that the `needs_sphinx` field identifies the minimal version of Sphinx that can be used to build the docs. The actual version that is used to bui

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

13.01.21 01:28, Victor Stinner пише: > I looked at Sphinx and Python versions of Debian, Ubuntu and Fedora: > https://bugs.python.org/issue42843#msg384963 > > In my list, there is only Debian Buster (stable) which doesn't have > Sphinx 3 yet. It uses Python 3.7 and so would not be affected by > Py

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

12.01.21 22:38, Julien Palard via Python-Dev пише: > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that > we could work around, some are bit harder, so we may need to bump > `needs_sphinx = '3.2'` (curr

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

Hi Matthias, Le 2021-01-13 à 12:27, Matthias Klose a écrit : > That's not true. Ubuntu 20.04 LTS still sees updates to subminor Python 3.8 > versions, having sphinx 1.8.5. I do agree to *not* bump our Sphinx dependencies for already published Pythons. Would it be OK to bump Sphinx to 3.2 for Py

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

Le 2021-01-13 à 00:28, Victor Stinner a écrit : > Since documentation changes are backported to 3.8 and 3.9 stable > branches, if we increase the minimum required Sphinx version in > master, I would prefer to also increase it in 3.8 and 3.9 branches. Bumping a dependency on the next release is alr

[Python-Dev] Re: 3.10 change (?) for __bool__

Hi Rob, On 13/01/2021 12:18 pm, Rob Cliffe wrote: On 12/01/2021 15:53, Mark Shannon wrote: In master we convert `if x: pass` to `pass` which is equivalent, unless bool(x) has side effects the first time it is called. This is a recent change. Can you please confirm that this optimisation ON

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

Le 2021-01-13 à 00:09, Senthil Kumaran a écrit : > Wouldn't this a bug with Sphinx? No, this is a documented breaking change between Sphinx 2 and Sphinx 3. > Why would that be special cased with a flag (strip_signature_backslash)? The strip_signature_backslash has been introduced to allow Sphinx

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On 13.01.2021 3:12, Senthil Kumaran wrote: On Wed, Jan 13, 2021 at 02:53:30AM +0300, Ivan Pozdeev via Python-Dev wrote: I support keeping same Sphinx version across all the supported python versions. This is not a sustainable route since this way, there's no way to change the version at all.

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

On 1/13/21 12:28 AM, Victor Stinner wrote: > Since documentation changes are backported to 3.8 and 3.9 stable > branches, if we increase the minimum required Sphinx version in > master, I would prefer to also increase it in 3.8 and 3.9 branches. > > I would prefer to not have to check manually if

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Wed, 13 Jan 2021 02:08:01 -0800 Emily Bowman wrote: > Even if you define __bool__() as returning a bool, and > error/undefined behavior otherwise, that doesn't eliminate side > effects. Is it even possible to nail down a definition to the point > that you can say, "Thou shalt not muta

[Python-Dev] Re: 3.10 change (?) for __bool__

On 1/12/21 11:27 PM, Chris Angelico wrote: The language can also be defined in an optimization-friendly way, though. Consider how we got positional-only arguments in Python: first they existed in C-implemented functions in CPython, even though they couldn't exist in pure Python code, and then th

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 9:08 PM Emily Bowman wrote: > > Even if you define __bool__() as returning a bool, and error/undefined > behavior otherwise, that doesn't eliminate side effects. Is it even possible > to nail down a definition to the point that you can say, "Thou shalt not > mutate or ca

[Python-Dev] Re: 3.10 change (?) for __bool__

Even if you define __bool__() as returning a bool, and error/undefined behavior otherwise, that doesn't eliminate side effects. Is it even possible to nail down a definition to the point that you can say, "Thou shalt not mutate or cause anything" and have it meaningfully enforced in the compiler o

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 8:02 PM Ethan Furman wrote: > > On 1/12/21 11:27 PM, Chris Angelico wrote: > > On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote: > > >> Optimizations are an implementation detail, and implementation details > >> should not change the language. > >> > > > > The language c

[Python-Dev] Re: 3.10 change (?) for __bool__

On 1/12/21 11:27 PM, Chris Angelico wrote: On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote: Optimizations are an implementation detail, and implementation details should not change the language. The language can also be defined in an optimization-friendly way, though. Consider how we go

[Python-Dev] Re: 3.10 change (?) for __bool__

Hello, On Wed, 13 Jan 2021 18:27:07 +1100 Chris Angelico wrote: [] > > Optimizations are an implementation detail, and implementation > > details should not change the language. > > The language can also be defined in an optimization-friendly way, > though. Consider how we got positional-only