gpshead
Several of us were/are/TBD also involved in both long term strategic leadership and maintenance of the open source CPython project itself. That direct feedback line from a major diverse needs user into the project and ecosystem was valuable for the world.
The reason I stayed on this team for 12+ years is as zem said. It was an ideal impactful alignment of people, abilities, priorities, and work life balance. My prior teams at Google... were often not.
For the first half of our Python teams existence, there were only ~5 of us. Many early years were spent paying down internal tech debt accumulated from prior years of neglecting to have a strong Python strategy and letting too many do their own thing. Python was one of the very first languages used widely at Google. It was the last major backend language to get a language team.
Signed, -- the now-ex runtimes TL
Read as much into that statement as you want.
:cry:
Digging through our history, a person who reported the same thing earlier than you never got a response at all. Like I said, we've identified organizational issues to be addressed.
(I honestly don't know who should be "credited" on the CVE nor do I have control over that, sorry)
There was no fighting. As soon as Mark piped up I was extremely pleased to see that he had found something that should've been obvious that we'd overlooked in the process of doing everything spread over time. Mark wasn't able to review the PR code before it was made public due to the current processes (lack of...) we're working to improve for the Python security response team.
"pedantically correct" was not intended to be read as passive aggressive. I use that term to mean exact vs almost when it comes to computations. I didn't need convincing. I wanted the reasoning to be made understandable to everyone else in the future (future selves included) who was going to read this code later. I still think there is room for better explanation of the math but that is true for large parts of Objects/longobject.c anyways.
I find your interpretation of events... amusing. :P
But also look at MyPy's internal MyPyC if you want something that uses type information for some speedups.
MyPy itself _runs_ under Python 3.
Pytype started with larger goals: It focused on static analysis and type inference; much more so than any of the other Python type checkers today do.
PyType, like MyPy, is also capable of analyzing Python 2.7 code because existing codebases have a ton of that and understanding types can help when porting it to 3. A couple years from now will anyone care? We hope not!
Performance is a problem for dynamic language type analyzers. Particularly so for Python where CPython is slow yet analyzers want to be self hosted in the language they're written to analyze. Very interesting, though not wholly surprising, to see Pyre and Pyright choose to implement in other faster languages. MyPy also has MyPyC internally which is doing a very Cython-esque translation of some of their performance hot spots into CPython API C code for a speedup.
Interesting times.
Desktop in 2019? good luck. Adobe or Apple.
What if I also wanted my wrapper available on a non CPython VM? The proper way to use PyPy is not via its fake CPython API support (slow and memory hungry). Imagine if a PyPy Generator were added to CLIF. It'd use the same interface definition Parser but generate an entirely different set of code. In PyPy's case that would probably be a C library wrapping the C++ for generated cffi based Python code to interact with.
Admittedly all hypothetical here until other Python VMs have CLIF Generator implementations.
But a "there be dragons" caveat applies as getting the CPython API correct is complicated. Reference counting and error checking bugs are common in hand written CPython C API code.
For most cross language bindings the primary goal is to "just work reliably". Optimization can happen later after you have profiles to figure out where it is worth doing and in what way.
Interesting stat: Around 80% of our the Python C++ extension module wrappings being added to our code base are now being done using CLIF instead of SWIG. We are actively working on forbidding new Python SWIG wrappers from being added and migrating important legacy wrappings off of it onto CLIF.
Who am I? I am TL of the team that create CLIF (design and code reviewer, _not_ a primary author; they can identify themselves as they see fit). -gps@