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

[Paul Sokolovsky]

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 arguments in Python: first
> they existed in C-implemented functions in CPython, even though they
> couldn't exist in pure Python code, and then the functionality got
> added to the language definition, thus permitting the optimization.

In this case, the culprit seems to be that __bool__() and many other
"special" methods may have side effects. So, just as "const" annotation
would be useful for variables, "pure" (side-effect free) annotation
would be useful for functions.

But that alone won't help due to too-dynamic nature of Python. It's not
much of an optimization if, at runtime, at each call-site, you need to
check whether a function is pure to decide if you have to call it, or
may skip it. Instead, that rather be done at compile time.

But checking which method (pure or impure) will be called when is again
complicated statically in Python. What to do about that? Well, we can
introduce, ahem, some "strict" mode, in which *all* __bool__(),
__gt__(), and friends must be declared pure, and for good measure,
returning bool. Then we know we can skip any such method call.

You see, all heresy starts from small things...

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/4P52JORZ4WBCPC6DERRITDRETEFWT73H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

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 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 the functionality got
added to the language definition, thus permitting the optimization.


1. What optimization?
2. Did the language change because of the optimization?


Or consider dictionary lookup. Most people treat it as "find a key
which is equal to the one you're looking for", but the actual
definition is "find a key which is identical to, or equal to, the one
you're looking for".


Exactly.  The definition, i.e. language spec, says identity, then equality.


The topic under discussion is a language definition. Choosing to
permit the optimization doesn't mean that the implementation detail
changes the language. Choosing to deny it means there won't be an
optimization.


There are, I am sure, many optimizations that are not possible because of Python's dynamism.  `if ` is 
supposed to evaluate `bool(something)`, regardless of what comes after.



I personally don't see any reason to force Python to calculate
something unnecessarily, given that this is *already* happening in
other situations (see the "if a and b:" optimization, which doesn't
boolify twice).


Sure, and I agree that calling `bool()` a second time is wasteful, as well as possibly confusing -- Python already has 
the answer from the first `bool()` call, so why would it need to do it again?  That seems a matter of correctness, not 
optimization.


--
~Ethan~
___
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/MNP25T5WJ5YIVIOJJFTU5QSO5ME6BUED/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 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 the functionality got
> > added to the language definition, thus permitting the optimization.
>
> 1. What optimization?
> 2. Did the language change because of the optimization?

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, they'd error out.

And yes. PEP 457 and then PEP 570 introduced real positional-only
arguments, and part of the debate surrounded the question "should we
require that all C-implemented functions support keyword args?". Why
have a performance hit on all C functions just for the sake of an
arbitrary consistency? Instead, the language definition was changed to
make this possible - and now we have, for instance, "len(obj, /)",
which clearly does not accept len(obj="x"), but does accept len("x").

> > Or consider dictionary lookup. Most people treat it as "find a key
> > which is equal to the one you're looking for", but the actual
> > definition is "find a key which is identical to, or equal to, the one
> > you're looking for".
>
> Exactly.  The definition, i.e. language spec, says identity, then equality.

Right. The definition is set to permit the optimization. Therefore the
optimization cannot be in violation of the spec.

> > The topic under discussion is a language definition. Choosing to
> > permit the optimization doesn't mean that the implementation detail
> > changes the language. Choosing to deny it means there won't be an
> > optimization.
>
> There are, I am sure, many optimizations that are not possible because of 
> Python's dynamism.  `if ` is
> supposed to evaluate `bool(something)`, regardless of what comes after.

It doesn't, though. There is a difference between:

if a and b: ...

and

x = a and b
if x: ...

The first one will boolify a only once; the second will figure out
what bool(a) is before the assignment, and then (if it's false)
boolify it again in the 'if' statement.

Current builds of Python 3.10 optimize this away too:

if a or 1: print(1)

Regardless of the truthiness of a, the print call will happen.

(Note that a is still *evaluated*. It's just not queried for
truthiness. For instance, "if f() or 1:" will still call the function;
it just won't call __bool__() on the return value.)

> > I personally don't see any reason to force Python to calculate
> > something unnecessarily, given that this is *already* happening in
> > other situations (see the "if a and b:" optimization, which doesn't
> > boolify twice).
>
> Sure, and I agree that calling `bool()` a second time is wasteful, as well as 
> possibly confusing -- Python already has
> the answer from the first `bool()` call, so why would it need to do it again? 
>  That seems a matter of correctness, not
> optimization.
>

Is it? It means that there's a visible difference between putting it
in a variable and doing it inline. If it's okay to do that, then why
is it not okay to remove the bool check when it can't affect the
result?

In theory, "x = (expr)" followed by "if x:" should perform the exact
same checks as "if (expr):"; if it's okay to violate that principle
for "if a and b:", then why not for "if a: pass"? Either way, the
interpreter knows that any sane __bool__ function cannot affect the
result.

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/RK36KL2EH5I54W76INZ64OBFJ5BBY5L7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Emily Bowman]

 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 or interpreter?

-Em

On Wed, Jan 13, 2021 at 12:18 AM Paul Sokolovsky  wrote:

> 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 arguments in Python: first
> > they existed in C-implemented functions in CPython, even though they
> > couldn't exist in pure Python code, and then the functionality got
> > added to the language definition, thus permitting the optimization.
>
> In this case, the culprit seems to be that __bool__() and many other
> "special" methods may have side effects. So, just as "const" annotation
> would be useful for variables, "pure" (side-effect free) annotation
> would be useful for functions.
>
> But that alone won't help due to too-dynamic nature of Python. It's not
> much of an optimization if, at runtime, at each call-site, you need to
> check whether a function is pure to decide if you have to call it, or
> may skip it. Instead, that rather be done at compile time.
>
> But checking which method (pure or impure) will be called when is again
> complicated statically in Python. What to do about that? Well, we can
> introduce, ahem, some "strict" mode, in which *all* __bool__(),
> __gt__(), and friends must be declared pure, and for good measure,
> returning bool. Then we know we can skip any such method call.
>
> You see, all heresy starts from small things...
>
> []
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
> ___
> 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/4P52JORZ4WBCPC6DERRITDRETEFWT73H/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/JEJGH465VBGKORF5KMIZHX56WWB7MZUW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 cause anything" and have it meaningfully enforced in the compiler 
> or interpreter?
>

Yes - just say "will be called when the interpreter needs to know the
booleanness of the object", and don't mandate that it be called if the
interpreter already knows. If someone writes a __bool__ function that
decrements a counter and returns True if it's still above zero, then
they're shooting themselves in the foot, and we don't have to protect
them.

It's like having __iter__ return an object on which __iter__ doesn't
return self. There's no protection in the language to stop you from
creating such a monster, but you'll run into problems sooner or later
if you do, and it's not a bug in Python.

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/RN7SAZ3X4YM2KEHNVMAXDNPLQFWVY7NJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Larry Hastings]

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 the functionality got
added to the language definition, thus permitting the optimization.


I wouldn't describe positional-only parameters as an "optimization".  
They were created to add expressiveness to Python code, not to make 
Python code faster.  The classic example is the dict constructor: 
technically, you couldn't implement it correctly in pure Python code, 
because it had a parameter (the iterable) that could not be a named 
parameter.  Any name you gave it would preclude passing in that name as 
a name=value argument.


Parsing positional-only parameters is often faster than parsing named 
parameters, for obvious reasons.  But this is really small stuff, 
drowned out by almost any other variation in your code.



Cheers,


//arry/

___
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/OO4RDFHB4RXW6TW35HSW2NRRTUSY6PRH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Sokolovsky]

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 mutate or cause anything" and have
> it meaningfully enforced in the compiler or interpreter?

Yes, sure, "pure" annotation on a function would (ideally/eventually)
need "typechecking". We could start with simple rules like: a) a pure
function should not mutate any objects which it didn't create; b) for
"mutation" also counts passing objects to (other) non-pure functions.
The hardest part is again to know which of these other functions is pure
or impure. Runtime checking should not be the aim to shoot for. There
should be a way to preserve as much as possible of Python's dynamic
nature that we all love, yet avoid runtime lookups.

The above "purity" conditions are also too restrictive, so would need
to be extended/elaborated (which would certainly require more detailed
annotations; fortunately, we all already accepted annotations to be a
part of Python's nature, so wanting to use them more shouldn't come as
surprise).

> 
> -Em
> 
> On Wed, Jan 13, 2021 at 12:18 AM Paul Sokolovsky 
> wrote:
> 
> > 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 arguments in Python:
> > > first they existed in C-implemented functions in CPython, even
> > > though they couldn't exist in pure Python code, and then the
> > > functionality got added to the language definition, thus
> > > permitting the optimization.  
> >
> > In this case, the culprit seems to be that __bool__() and many other
> > "special" methods may have side effects. So, just as "const"
> > annotation would be useful for variables, "pure" (side-effect free)
> > annotation would be useful for functions.
> >
> > But that alone won't help due to too-dynamic nature of Python. It's
> > not much of an optimization if, at runtime, at each call-site, you
> > need to check whether a function is pure to decide if you have to
> > call it, or may skip it. Instead, that rather be done at compile
> > time.
> >
> > But checking which method (pure or impure) will be called when is
> > again complicated statically in Python. What to do about that?
> > Well, we can introduce, ahem, some "strict" mode, in which *all*
> > __bool__(), __gt__(), and friends must be declared pure, and for
> > good measure, returning bool. Then we know we can skip any such
> > method call.
> >
> > You see, all heresy starts from small things...
> >
> > []
> >
> > --
> > Best regards,
> >  Paul  mailto:pmis...@gmail.com
> > ___
> > 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/4P52JORZ4WBCPC6DERRITDRETEFWT73H/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >  



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/TCG7237FJILE4MVKBXSTTQEIR6CX7VFJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Matthias Klose]

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 a doc backport PR is
> still compatible with Sphinx 2 or not. If we skip some doc backports,
> conflicts will become more likely with following doc backports.
> 
> --
> 
> 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
> Python 3.8 changes.

That's not true. Ubuntu 20.04 LTS still sees updates to subminor Python 3.8
versions, having sphinx 1.8.5.

Matthias
___
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/SN24BKRX3PIIYMGDGX563HHGZXTRCHUI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Pozdeev via Python-Dev]

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.


By supported, I mean the active versions that we backport patches to.
Same as what Victor said.


That's what I meant, too.

E.g. when 3.11 comes out and 3.8 is EOL, it will still have to stick with the 
old sphinx because 3.9 and 3.10 do -- and so on ad infinum.




--
Senthil


--
Regards,
Ivan
___
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/XLZMI252675AR44AL32VJCE7763X5YAJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Julien Palard via Python-Dev]

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 3 to 
behave like Sphinx 2 in respect of backslash in signatures. It would 
allow us to write Sphinx 2 and Sphinx 3 compatible doc.

> I noticed that you suggested not to backport this PR
> https://github.com/python/cpython/pull/24142

I'm against changing the major version of the Sphinx we use during the 
life of a release. It looks already hard for distrib maintainers to 
handle a Sphinx upgrade for the next release, let's not upgrade it on 
live releases.

In other words: it may or may not be OK to bump Sphinx for a minor 
Python release, but it's clearly not for a patch release (only my point 
of view).

> * Would that mean we have to careful not to use/merge sphinx features like
>`no-trim-doctest-flags` to older docs?

Exactly: backporting a Doc commit could not work, but it would be 
spotted by the tests and not mergeable, as we use `-W` flag of Sphinx 
build (treat warnings as errors).

> * What would it take to keep all active versions of Cpython docs build at the
>same min version (possibly 3.2)?

As said previously, I don't think it's OK to bump Python 3.7 to use 
Sphinx 3 now.

> As Cpython developer, I see nothing bad, but platform maintainers seem to have
> some concerns, and it will be good to see points against this.

That's exactly why I opened this thread, if it's OK for all platform 
maintainers, we'll do this, but if not, we can revert a few commits and 
postpone the Sphinx upgrade, no worries.

-- 
[Julien Palard](https://mdk.fr)
___
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/W5QVYL5L4DMA2BR5J5NNWRJ2KDMRNGX7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mark Shannon]

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 ONLY applies to bare 
names, i.e. NOT


     if x(): pass
     if x.y: pass
     if x+y: pass



The optimization doesn't apply to the expression, but the test.
The optimizer (might) transform

if x+y: pass

to

x+y

But the expression is still evaluated.
Sorry for the confusion, I should have been clearer in my example.
It is the call to `bool()` that *might* be eliminated.

Cheers,
Mark.





Thanks
Rob Cliffe

___
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/YZMA3ABVUKJ3PDFO4BS56QRSL4YCC3DJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Julien Palard via Python-Dev]

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 already hard, I don't think 
we can bump dependencies on current releases like Python 3.8.

> I would prefer to not have to check manually if a doc backport PR is
> still compatible with Sphinx 2 or not.

As we're using `-W` flag of sphinx-build, the tests would spot it and 
mark the backport PR as not mergeable. The doc would diverge from a 
branch to another, but it already does, so I do not worry a lot about 
conflicts.

> The alternative is to keep Sphinx 2 support, use
> strip_signature_backslash and don't use :no-trim-doctest-flags: ?

Exact, totally doable for a few years to ease the migration, we could 
even keep Sphinx 1.8 support for a few years as it still works with 
those two "fixes" applied (it would imply reopening 
https://bugs.python.org/issue36675 but I'm not against it).

-- 
[Julien Palard](https://mdk.fr)
___
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/E77DZXH4JCQS2Y2TGUHW7QB2Q546SJCI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Julien Palard via Python-Dev]

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 Python 3.10? Or would it be 
better to keep Sphinx 2 compatibility for a few years (how many?) before 
requiring Sphinx 3?

Bests,
-- 
[Julien Palard](https://mdk.fr)
___
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/PFKZ72A5HD5ZTOXKLN36RYI22Z3QGCGO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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'` (currently it is 1.8).

Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it
cause problems with builting documentation on Ubuntu?
___
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/EJWTFPHZUX522RNCTIGAAOHWD23VD7NQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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
> Python 3.8 changes.

Also Ubuntu. Ubuntu 20.04 has only Sphinx 1.8.5, but Python 3.8 and 3.9.
___
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/4AUTIFRA4ANJMYCFTUCY2RVUIVI3LRJC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Carol Willing]

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 build the docs is in the `requirements.txt` file.


On Wed, Jan 13, 2021 at 7:29 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 bit harder, so we may need to bump
> > `needs_sphinx = '3.2'` (currently it is 1.8).
>
> Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it
> cause problems with builting documentation on Ubuntu?
> ___
> 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/EJWTFPHZUX522RNCTIGAAOHWD23VD7NQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/S53K4P272EE73EF2NLZWS5DVNR6VJG3R/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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, they'd error out.

That's an unfortunate limitation of the docs, not a language feature. 
One might even call it a documentation bug.


> And yes. PEP 457 and then PEP 570 introduced real positional-only
> arguments, and part of the debate surrounded the question "should we
> require that all C-implemented functions support keyword args?". Why
> have a performance hit on all C functions just for the sake of an
> arbitrary consistency? Instead, the language definition was changed to
> make this possible - and now we have, for instance, "len(obj, /)",
> which clearly does not accept len(obj="x"), but does accept len("x").

Sorry to be pedantic here... oh who am I fooling, I'm not sorry at all 
*wink*

I think that if we are to be precise, and we should be, Python the 
language has always supported positional-only arguments. What we lacked 
was syntax for declaring named positional-only **parameters**.

There has always been at least two ways to implement positional-only 
arguments:

- write your function in C;

- or use `*args` and process them yourself.

So that's not a new feature. The new feature gained in 3.8 was syntax to 
define names for positional-only parameters in def statements.

This may not have been really obvious until after PEPs 457 and 570 
because we were (and still are) fairly blasé about the difference 
between arguments and parameters, and of calling things "positional" 
regardless of whether they were actually positional-or-keyword or 
positional-only.

In any case, this is very much a red herring. Function call syntax is 
not an optimization, it is a syntactic feature of the language. The 
ability to pass an argument by position, position-or-keyword, or keyword 
is an element of language design. The choice of which ones to support 
may be influenced by concerns about efficiency and speed, but that's as 
far as it goes.

I think your earlier example of short-cutting equality tests with 
identity tests is more relevant here.


[...]
> In theory, "x = (expr)" followed by "if x:" should perform the exact
> same checks as "if (expr):"; if it's okay to violate that principle
> for "if a and b:", then why not for "if a: pass"? Either way, the
> interpreter knows that any sane __bool__ function cannot affect the
> result.

Of course they can: the method can fail and raise an exception. That 
could be due to a bug, or by design, as in numpy arrays and (soon) 
NotImplemented.

Sane `__bool__` methods can have useful side-effects. More than once 
I've debugged code by sticking some logging inside a method I knew would 
be called, and that method could as easily be `__bool__` as any other.


-- 
Steve
___
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/RH2SYWCCCGZGDMPXWHJ5VMIKK3EQJIVZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 or cause anything" and have it meaningfully enforced in
> the compiler or interpreter?

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. But trying to retrofit that 
into Python would probably be about as hard as building a restricted 
mode, and for similar reasons.)

Besides, we probably don't want to prohibit side-effects in `__bool__`. 
That would prohibit useful tricks such as putting logging calls into a 
method you are trying to debug.


-- 
Steve
___
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/L3M6RLVJ44VN4S34RYJTROSAZMUEPGWM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Sokolovsky]

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 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 or interpreter?  
> 
> 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. But trying to retrofit
> that into Python would probably be about as hard as building a
> restricted mode, and for similar reasons.)
> 
> Besides, we probably don't want to prohibit side-effects in
> `__bool__`. That would prohibit useful tricks such as putting logging
> calls into a method you are trying to debug.

Surely, if we do that, we wouldn't use Haskell's definition of
purity ;-). Rather, a practical definition of purity, Python-style. For
example, print() would be considered "pure", as its purpose is to
provide program output, not arbitrarily change program state (so, all of
__str__, __repr__, __format__ would need to be pure, but if someone
overrode print() to shoot at random modules/data at them, then they
shoot themselves in the feet, nothing else). 

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/44IGY7CWR3OPM2RN64GJHXOML4ZMW3IX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

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 bit harder, so we may need to bump
> > `needs_sphinx = '3.2'` (currently it is 1.8).
>
> Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it
> cause problems with builting documentation on Ubuntu?
>

Why can't contributors install from PyPI? The venv created by the
Docs/Makefile does a pip install, so I don't see why what version of Sphinx
is packaged via APT is a critical blocker in upgrading Sphinx.
___
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/Y7ZM24JX4OIQBBWTKVWUMK74LQIWGAG6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Gregory P. Smith]

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 breaking change (as appears to be the case?), we
should update our docs for all versions we backport doc changes to to use
the most modern version (along with the docs themselves).

We should explicitly not care at all about people using external sphinx
installs that are not fetched at the correct version via our Doc tree's
Doc/requirements.txt.

That some distros want to use their own incompatible-version packaged
version of sphinx to build our docs is on them to handle on their own.  Not
on the CPython project.  That was never a guaranteed thing that would
work.  Until now, they merely got lucky.  This is a docs build-time
dependency with no impact on anything at runtime so we should be free to
change versions as we see fit.

-gps


On Wed, Jan 13, 2021 at 8:25 AM Carol Willing  wrote:

> 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 build the docs is in the `requirements.txt` file.
>
>
> On Wed, Jan 13, 2021 at 7:29 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 bit harder, so we may need to bump
>> > `needs_sphinx = '3.2'` (currently it is 1.8).
>>
>> Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it
>> cause problems with builting documentation on Ubuntu?
>> ___
>> 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/EJWTFPHZUX522RNCTIGAAOHWD23VD7NQ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/S53K4P272EE73EF2NLZWS5DVNR6VJG3R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/Y2ZCBJAF7NL5CP7GDGYVAICBYBIVDTC2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

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 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'` (currently it is 1.8).

Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it
cause problems with builting documentation on Ubuntu?


Why can't contributors install from PyPI? The venv created by the 
Docs/Makefile does a pip install, so I don't see why what version of 
Sphinx is packaged via APT is a critical blocker in upgrading Sphinx.


I trust the CPython core devs, and I trust my distro's processes and 
packagers, but not necessarily the PyPI maintainers of Sphinx's 
requirements.

___
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/3YHMI555EEYAQXO3NBITAGZLMKQVAN4E/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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.


All functions are pure in Haskell -- not sure if that counts
as "doing something like that". Retrofitting it into
Python would turn it into a very different language.

--
Greg
___
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/7BOWX7N54CA6FPGJDCQSEH73MQZKJEEE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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 still cause
a visible change in the program's behaviour.

--
Greg
___
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/B6VDVU7UOB5QNILEJ44J7JOSVBF7WDBF/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Sokolovsky]

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 really help with optimisations,
> though, because optimising away a print() call would still cause
> a visible change in the program's behaviour.

But nobody talked about optimizing away generic "pure"-annotated
functions (which would differ from "mathematical" definition of
purity), only about optimizing "pure" *dunder* methods (which are by
definition special methods, which are called implicitly; or not called,
which is the aim we discuss).

"Pure" annotation on other functions are drawn only to verify that a
dunder itself is indeed "pure".

And "pure" is of course a pretty rough term meaning "not causing
*non-local* side effects". print() in that regard causes only localized
side effect of output appearing on terminal. print() also can be
redefined to output to io.StringIO, and it still will be "pure", as
side effects will be localized to just that io.StringIO object (which
has dedicated purpose to be print's buffer in the first place). But if
user redefines print() to e.g. manipulate sys.path, it's now causes
non-local side effects, and thus breaks API contract re: "purity".
 
> -- 
> Greg

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/B6E2NZYIURXDRZ336TBAVCANI666KH4A/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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 __bool__ that calls print() is also pure, so there's
nothing wrong with optimising it away, right?

--
Greg
___
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/KFP2TZXVJAQROMILOOM3CJT24DJESBHJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Terry Reedy]

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 we decide that print() is pure,
then a __bool__ that calls print() is also pure, so there's
nothing wrong with optimising it away, right?


I say 'yes', because the purpose of logging is to document what happens, 
and if nothing happens, there is nothing to document.  Wrapping a 
.__bool__ in a logging decorator might be part of testing it.



--
Terry Jan Reedy
___
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/NRJT2YZ2U73ZYFZPAKKPXFBKGLJMBG3M/
Code of Conduct: http://python.org/psf/codeofconduct/