11:52 <BarrensZeppelin> The parser changes for PEP695 (type statement & type parameter syntax) are done now, but the tricky runtime support parts remain... @cfbolz Would it make sense to merge the changes and port the stdlib now? A lot of the support classes from the typing module were re-implemented in C, which is annoying...

11:55 <nimaje> reimplemented like most other modules where some interface module imports the C version if availible and a pure python version if not or without a pure python version?

11:56 <BarrensZeppelin> Without a pure python version, unfortunately

11:59 <nimaje> doesn't cpython care about alternative implementations anymore? I throught that was the main reason for those double implementations

12:03 <BarrensZeppelin> 🤷‍♂️ I found this post by Zelle J., which explains some design decisions: https://jellezijlstra.github.io/pep695.html#runtime-objects I should've found this earlier 😅

12:04 <BarrensZeppelin> Jelle Z.*

12:09 <BarrensZeppelin> I probably also should've looked at the original PR for CPython, which is massive: https://github.com/python/cpython/pull/103764

12:27 <BarrensZeppelin> There's some pure python code in typing-extensions that may be useful as a starting point.

12:34 <lazka> python fallbacks came up in the forum recently: https://discuss.python.org/t/accelerator-for-ascii85-base85/105415

12:34 <lazka> they decided to drop them in that case

12:35 <lazka> (the code moved to a module already missing fallbacks though)