[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization

[Ken Jin]

Hi Phillip, thanks for your interest in CPython.

How Python views your code isn't how you view your code. CPython views source 
code instead as something called "bytecode/wordcode". This bytecode is a 
lower-level intermediary language that the CPython interpreter executes. You 
can read more about bytecode at the documentation for the dis module [1].

Operations are thus viewed at the bytecode level. The inline caching is done on 
a per-bytecode basis. A complicated program would be split into many bytecode 
that each does a smaller operation relative to the larger program. This is why 
our guards when using information from the inline cache are very simple, 
because the operations themselves are relatively simpler to something as big as 
a function. This is also how we can ensure that side effects in our operations 
don't break anything.

> I actually find myself often factoring such data out of loops in Python,  
> whereas in C I would just leave that to the optimizer/compiler.

The compiler in CPython can't really do that because it's not safe in Python. 
The user could've overridden `__add__` to do more things than just addition.

[1] https://docs.python.org/3/library/dis.html
___
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/UVKPPMKOAN5SNMARXIQAFOXCYO6JM5K2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization

[Philipp Burch]

On 15.09.22 00:05, Jeremiah Gabriel Pascual wrote:

I've frequently explored the new adaptive, inline caching code generated by 3.11. 
"inline caching" does not mean result caching (like what C/C++ might do) here, 
but rather it should mean the caching of info used for the adaptive instructions. That 
means the bytecode stays the same except for the adaptive instructions and the changed 
`CACHE`s below each adaptive instruction, which should *always* be skipped due to the 
possibility of misinterpretation as other instructions.



Oh, thanks for the clarification. Looks like I've hoped for too much 
when reading about caching. Maybe sometimes in the future, who knows...


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

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Philipp Burch]

Hi all,

I've only here found out that there is a discussion going on about those 
none-aware operators and my first thought was "great, finally!". FWIW, 
I'd be happy with the syntax suggestion in the PEP, since '?' looks 
rather intuitive to me to mean something like "maybe".


However, I then read the mentioned post of Steve Dower, with the final 
summary:


> So to summarise my core concern - allowing an API designer to "just 
use None" is a cop out, and it lets people write lazy/bad APIs rather 
than coming up with good ones.


This is a very good point. In fact, I've never really thought about it 
that way and of course he's totally right that "SomeType | None" (or 
Optional[SomeType], which also somehow made me feel that this usage is 
fairly intended) is not optimal, at least for user defined 
types/classes. The problem is, that I never actually thought about his 
suggested way. And I wouldn't be surprised if this holds for many other 
people as well.


Maybe it would be great to boldly mention these thoughts in the 
documentation at an appropriate place. In my opinion, there are at least 
the following good places where this would fit nicely:


- The documentation of the dataclasses 
(https://docs.python.org/3/library/dataclasses.html), since this is 
probably the most common use case for the "| None" pattern. Going 
further, the dataclasses functionality might even be extended to make it 
simpler to generate such null-types (or however they are called), so 
that it is no longer "a tonne more work".


- Linters like pylint could emit a note when seeing the "| None" 
pattern, linking to the explanation about why it is possibly not the 
best way to do it.


- The documentation of the discussed None-aware operators. Since these 
new operators are closely coupled to the arguably suboptimal "| None" 
pattern, it is probably good to tell folks right there why they should 
consider better alternatives.


As mentioned, I absolutely see Steve's point. However, there are many 
Python scripts/programs working without a complex API, where this "| 
None" pattern may still have its legitimate uses and the none-aware 
operators can make code easier to read (and write).


Best regards,
Philipp
___
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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization

[Philipp Burch]

Hi Ken,

thank you for the inputs. Just one more comment:


I actually find myself often factoring such data out of loops in Python,  
whereas in C I would just leave that to the optimizer/compiler.


The compiler in CPython can't really do that because it's not safe in Python. 
The user could've overridden `__add__` to do more things than just addition.


I'm totally aware that Python, or dynamic languages in general, are 
terrible for any optimizer, because there is basically nothing that it 
can be sure about. However, this is exactly the point of marking 
functions as "pure". It would not make the code technically safe to 
optimize, but transfer the responsibility from the interpreter to the 
programmer. If the programmer says that something is safe to 
optimize/cache, then the interpreter can't be blamed if something breaks 
when it actually does so.


On the other hand, a language as dynamic as Python probably is just not 
designed for an optimizer, so either you do it by hand or use an 
extension module  to speed critical parts up. Fair enough.


Best regards,
Philipp
___
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/JA7YE6V4APZT7QZXA6SASVWXEQJTWY5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Guido van Rossum]

Personally I think returning None is a fine API design, and IMO the
concerns about this pattern are overblown. Note that X|None is no different
than the "Maybe X" pattern that functional programmers are so fond of.

On Mon, Sep 19, 2022 at 8:02 AM Philipp Burch  wrote:

> Hi all,
>
> I've only here found out that there is a discussion going on about those
> none-aware operators and my first thought was "great, finally!". FWIW,
> I'd be happy with the syntax suggestion in the PEP, since '?' looks
> rather intuitive to me to mean something like "maybe".
>
> However, I then read the mentioned post of Steve Dower, with the final
> summary:
>
>  > So to summarise my core concern - allowing an API designer to "just
> use None" is a cop out, and it lets people write lazy/bad APIs rather
> than coming up with good ones.
>
> This is a very good point. In fact, I've never really thought about it
> that way and of course he's totally right that "SomeType | None" (or
> Optional[SomeType], which also somehow made me feel that this usage is
> fairly intended) is not optimal, at least for user defined
> types/classes. The problem is, that I never actually thought about his
> suggested way. And I wouldn't be surprised if this holds for many other
> people as well.
>
> Maybe it would be great to boldly mention these thoughts in the
> documentation at an appropriate place. In my opinion, there are at least
> the following good places where this would fit nicely:
>
> - The documentation of the dataclasses
> (https://docs.python.org/3/library/dataclasses.html), since this is
> probably the most common use case for the "| None" pattern. Going
> further, the dataclasses functionality might even be extended to make it
> simpler to generate such null-types (or however they are called), so
> that it is no longer "a tonne more work".
>
> - Linters like pylint could emit a note when seeing the "| None"
> pattern, linking to the explanation about why it is possibly not the
> best way to do it.
>
> - The documentation of the discussed None-aware operators. Since these
> new operators are closely coupled to the arguably suboptimal "| None"
> pattern, it is probably good to tell folks right there why they should
> consider better alternatives.
>
> As mentioned, I absolutely see Steve's point. However, there are many
> Python scripts/programs working without a complex API, where this "|
> None" pattern may still have its legitimate uses and the none-aware
> operators can make code easier to read (and write).
>
> Best regards,
> Philipp
> ___
> 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/Q2MOF5CJ7LSSZMEMB43YVEXD6PFATYTA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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