Adding to the wonderful writeup by my now-ex teammate (thanks!):
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.
I keep wondering if it was as well given code I've had to wrangle that _wants_ twos compliment fixed size math in Python. Both signed and unsigned. But our language tries not to have a bazillion different basic types and the ill-defined Python <= 2 `int` being whatever the platforms `C long` could hold was not great so simplifying to a single integer type in 3 was still a net win AFAICT.
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)
If you don't understand why I cited the code of conduct and redirected discussion to a more appropriate forum for constructive discussion, go read our code of conduct vs the language that was being directed at us and what being linked from this toxic site was about to bring.
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
This is easy for huge corporations who live and breathe automated-DDoS protection without blinking an eye, but a major challenge for all of the little applications and small hosts.
Bad premise. It is not all about benefit to the person being vaccinated even in a low imputed immunity scenario. The unvaccinated fill up and overwhelm healthcare systems. That disrupts all medical care for everyone. By being vaccinated you are reducing the burden for everybody.
We'll link to this in ten years when you're still writing some Real Things in Python assuming this site even stays up that long and we have nothing better to do. ;)
MyPy is not owned by Dropbox. They use it and many significant contributors work there, so it is easy to get this impression. But it was started before that happened.
Nope. Our pytype project started before Mypy even existed. It was inspired first by https://developers.google.com/closure/compiler/'s success, and soon after inspired by TypeScript being released by Microsoft. MyPy came on the scene later in the same year we has started to work on early (unsuccessful) versions PyType. We didn't release pytype until ~2015 and didn't focus on making it usable in the OSS world until the last couple of years.
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.
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