> So much stuff just from the readme would introduce breaking changes to the Python ecosystem.

Being compatible with the rest of the Python ecosystem is the main reason why Cinder is built on top of CPython. Although yes, some features are indeed very experimental.

> in a world where we have type annotations, JITs feel like a massive step back. Stuff like mypyc could get us way further into high performance stuff

Ah, but that introduces a separate compilation step, which may not be tolerable in every situation.

Well, the compilation step is alredy present in current py -> pyc phase, it's just a matter of "extending" it. Also, look at how cython work

> Well, the compilation step is alredy present in current py -> pyc phase

Yes, but developers don't have to ever interact with it.

> Also, look at how cython work

Cython works by adding a separate build step. Changing a Cython module requires you to recompile it, which is avoided with a JIT.

Why would developers have to interact with a mypyc step any more than the pyc step? Why is “developers might have to interact with it” some kind of non-starter, as though having a compile phase is a worse evil than a hyper-slow language?

FWIW, I think we could probably buy ourselves a lot of latitude to optimize CPython by designating a much smaller API surface (like h.py) and then optimizations largely won’t have to worry about breaking compatibility with C-extensions (which seems to be the biggest reason CPython is unoptimized).

But in general I’ve lost faith in the maintainers’ leadership to drive through this kind of change (or similarly, to fix package management), so I’ve moved on to greener pastures (Go for the most part, with some Rust here and there) and everything is just so easy nowadays compared to my ~15 years as a Python developer.

> Why is “developers might have to interact with it” some kind of non-starter, as though having a compile phase is a worse evil than a hyper-slow language?

For big monoliths (like ours at IG), the server start-up can take more than 10sec, which is already super high for a "edit -> refresh" workflow. Introducing a Cython like compilation step is really a major drawback for every single developer.

For smaller projects, Cython works extremely well (and we do use it for places where we need to interface with C/C++).

> For big monoliths (like ours at IG), the server start-up can take more than 10sec, which is already super high for a "edit -> refresh" workflow. Introducing a Cython like compilation step is really a major drawback for every single developer.

Then skip it for your dev builds.

Can you elaborate on what you mean by "skip" Cython compilation on dev builds? How would you then test changes to Cython code?

So we weren’t talking about Cython specifically, but something Cython-like, i.e., we’re not talking about Cython’s special syntax but rather ordinary Python. This is important because it means that dev builds execute against CPython directly (i.e., your code begins executing immediately) while production builds use our hypothetical AOT compiler.

Python has a lot of crazy metaprogramming capabilities. Ability to inspect stacks, override import, and more...

The ones they removed are not commonly used at all.

I used to work on a project the used gevent. I'd almost describe it as monkey-patched async io. It's scary-clever.

Maybe there could be a subset of Python that removes the hyper dynamic parts so it can be compiled to something faster. Maybe I'm just describing Go.

> Maybe there could be a subset of Python that removes the hyper dynamic parts so it can be compiled to something faster.

What you’re describing is essentially Static Python (mentioned in the readme)

Is inspecting stacks used for logging backtraces during instrumentation?

I’ve gotten some great use out of it, personally.

I don't see why JIT cannot use type annotations to speed up the code.

But JIT also works on untyped or incompletely typed code.

According to the pypy people, the type annotations also don't provide the kind of information the JIT wants. The JIT cares about things like "this integer fits into a machine word" and "this parameter can be None but is almost always not None" so on. The type system doesn't concern itself with that.

It’s definitely true that there’s stuff a JIT would love to know that the type system can’t tell you. But that doesn’t mean there isn’t useful information available in type annotations. In particular it is possible to speed up attribute access and method/function calls a lot when target types are statically known.

Our approach to “int fits in a machine word” in Static Python is to require machine ints to be explicitly annotated as such, and then you opt in to limited size ints with overflow etc, in exchange for getting really fast arithmetic.

I mean if you care about perf you can do it in one step. It’s not that huge of an ask, and engineering wise “compile some typed code” is a hell of a lot more straightforward than “try to guess what I should speculatively compile at runtime”

There was a piece by v8 devs a while back where they ended up turning down JIT aggressiveness cuz it ended up making normal web pages slower (except for like Google Docs).

This is just me backseat-BDFLing “why do the hard thing when we could do the easy thing” tho

Typing a large legacy codebase written in a highly dynamic language is not as easy. Instagram is pretty large.

I have seen a very large codebase in a dynamic language at [redacted] that has been mostly converted to use a sophisticated type system. Certain core things have not been converted so far, though, but just marked with a lot of "proceed with caution" and "TODO" red flags. Making them typesafe in any conceivable way would break compatibility for large subsystems.

Sometimes a rewrite is the only way out of such a situation, but very few can afford it.

Instagram wrote https://github.com/Instagram/MonkeyType to help type their Python code

A couple of the folks who wrote MonkeyType (me and _carljm) also work on Cinder :)

> Typing a large legacy codebase written in a highly dynamic language is not as easy. > very few can afford it.

Starting a project in a highly dynamic language is a conscious choice with well-known properties. The second part is interesting, however. Essentially you are saying that gains from development velocity do not offset losses from technical debt, which is a strange observation. I would say it sort of hints at time to MVP being irrelevant business metric (startup runway/survivability aside) at best. This is contrary to typical startup truths.

At a certain scale, they do. Case in point: Twitter. They went through a painful transition but they did not have much choice.

But sometimes they don't. Case in point: YouTube, Instagram. Both of them are slowly migrating more and more Python code to different languages, but the amount of Python is still large, and AFAIK neither has plans to eschew it completely.

Time to MVP is a very relevant business metric. But the same thing that speeds you up in the beginning slows you down later on. If you architect your code past MVP to help replace the implementations of critical paths, it may help you down the line. (Micro)service architecture is one way to do that.

There's no requirement that type annotations be accurate.

With hidden classes and such it likely wouldn't matter much. You'd need them anyway for full dynamism

With Static Python we use type annotations in compilation, and we require them to be correct (they are runtime checked at boundaries with non-Static code and throw TypeError if wrong types are passed in.)

We haven’t gone the hidden classes route so far because it’s simpler to just look at attributes assigned in __init__ and annotated on the class and lock those into slots. If you’re writing typed Python you probably don’t do a lot of tacking extra ad hoc attributes onto instances, since type checkers don’t like that either.

Our JIT can use type information when available to improve speed. This is what the Static Python project described in the README is all about.