gpshead

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.

Signed, -- the now-ex runtimes TL

Well over 100m lines of Python as has been publicly stated several times over the years is not "very little".

Lutron Caseta has a telnet interface via an Ethernet port.

Read as much into that statement as you want.

uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

:cry:

You do realize that duckduckgo is primarily a frontend for bing right?

https://en.wikipedia.org/wiki/DuckDuckGo#Search_results

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.

Because there are.

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.

I wanted to upvote this comment but that just feels wrong.

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. ;)

Doesn't the local government want to tax those digital "currency" sales you used as a transfer mechanism as capital gains income?

Look up PyOxidizer.

But also look at MyPy's internal MyPyC if you want something that uses type information for some speedups.

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.

not to the same extent.

Yes it does: mypy can analyze Python 2 code - https://mypy.readthedocs.io/en/latest/python2.html

MyPy itself _runs_ under Python 3.

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.

Interesting times.

Flickr, the progenetor of photo tagging, remains a great place to do that.

Desktop in 2019? good luck. Adobe or Apple.

hiybbprqag for one - https://www.wired.com/2011/02/bing-copies-google/

You just filled up my BINGO card by saying "clearly" to indicate that you have no idea what you are talking about.

Neither do most US citizens.

Nobody likes an asshole, even a responsible one.

Thanks! Eek! An XML interface definition. In 2017!

It seems entirely reasonable for someone to create a MicroPython wrapper generator. It appears to have a C/C++ API so it should be similar to the existing CPython Generator and Runtime.

No goats need to be sacrificed in order for CLIF to do the right thing.

Metaprogramming such as pybind11 does is neat. Thanks for the pointer to the project. It still looks like manually written C extension modules to me based off of what I see in https://github.com/pybind/pybind11/blob/master/docs/basics.r.... Just much shorter code with a lot of the hard to get right details taken care of you. Good! Better than the status quo. But it doesn't abstract the problem away very much. (no doubt some will consider that a feature)

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.

There are always justifiable use cases for manually written Python bindings.

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.

I wondered how long it would take before someone posted CLIF here since we haven't put up a blog post about it yet... :)

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@

+1 trolling :)