[Python-Dev] Re: What's the rule for issuing line tracing numbers when using a tracing function?
> Does someone know if with the introduction of the new optimizations/quickening the PREDICT will still be used in 3.11? If there are 2 interpretation modes now, the PREDICT probably makes it hard to have both do the same things since the eval loop doesn't really match what the bytecode says due to the PREDICT. For your use case (tracing), the behavior should be the same as 3.10. PEP 659 and its current implementation doesn't run specialized bytecode when tracing and falls back to normal bytecode. The behavior of normal bytecode hasn't changed either (other than what's currently listed in the changelog). -KJ ___ 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/QHNPOVCQNCXN33QVCKSQUTPQJZAJCCR7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on Callable Syntax PEP
I agree with what Batuhan said. Adding on, I'm very concerned about the potential maintenance burden for Python implementations. Just for typing in CPython, some combination of the following knowledge is required to contribute code: 1. Metaclasses 2. Descriptors and CPython dunders 3. C internals due to PEP 585 and 604 4. If we throw in annotations internals, maybe we need some parser knowledge too, but this is usually not required. With the new callable syntax, that likely needs strong parser and compiler knowledge. I'm not claiming everyone needs to know all of the above to contribute (to the contrary, not knowing most of these is fine), but IMO the list is getting very long. I'd be sad if one day new typing contributors feel too overwhelmed by typing's implementation complexity (I admit sometimes feeling overwhelmed too). That said, thank you PEP authors for working to make Python's typing syntax more elegant. I hope my concerns didn't come across as overly harsh. - KJ ___ 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/YZG53T2D3UO6WZCR5U3N45GVAK3E7JPN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
@Lrupert > - Add coverage to X (tens of them, as separate PRs) I think I know the PRs you're referring to. For the record, some of the PRs tested hairy code paths in the module I maintain. I would have less confidence backporting bugfixes touching that code if we didn't have those tests (the code paths predate me maintaining the module). Sure, the PRs have overwhelmed me at times. However, I'd rather be overwhelmed with test coverage PRs now than with complaints I broke somebody's code on release day :). Inada Naoki wrote: > Some people may do "approval without review" to make their "Profile" > page richer, because GitHub counts it as a contribution. I noticed the same person you mentioned approving PRs right after I send an approval. It's very confusing for me. ___ 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/ZXFZD3CLUSJ533QXC73RQQG4EHYJPV6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization
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] PEP 699: Remove private dict version field added in PEP 509
I've created a new PEP to repeal PEP 509. Please post comments to the Discourse thread. Thank you! Discourse thread: https://discuss.python.org/t/pep-699-remove-private-dict-version-field-added-in-pep-509/19724 Link to the PEP: https://github.com/python/peps/blob/main/pep-0699.rst ___ 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/T7XUUNGL5RDO3CD3FANKWH7FKDLBDFA2/ Code of Conduct: http://python.org/psf/codeofconduct/
