9 ms·

So much stuff just from the readme would introduce breaking changes to the Python ecosystem. Part of the reason Instagram can get away with this is they likely

by rtpg 5y ago

So much stuff just from the readme would introduce breaking changes to the Python ecosystem. Part of the reason Instagram can get away with this is they likely have almost complete control of their dependencies and the like. But the changes they decide to make would not just work for everything. That being said I think we could get a lot of neat PEPs from this. EDIT: this is just my opinion , but 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 (and no black box hand waving for perf things).

nine_k 5y ago
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.
- nimish 5y ago
  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
  - _carljm 5y ago
    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.
- rtpg 5y ago
  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
  - nine_k 5y ago
    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.
    - huac 5y ago
      Instagram wrote https://github.com/Instagram/MonkeyType https://github.com/Instagram/MonkeyType to help type their Python code
      - kingmaker 5y ago
        A couple of the folks who wrote MonkeyType (me and _carljm) also work on Cinder :)
    - friendzis 5y ago
      > 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.
      - nine_k 5y ago
        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.
- wiml 5y ago
  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.
  - _carljm 5y ago
    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.
- _carljm 5y ago
  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.
czardoz 5y ago
> 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.
- _ZeD_ 5y ago
  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
  - czardoz 5y ago
    > 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.
    - throwaway894345 5y ago
      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.
crazypython 5y ago
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.
- nitrogen 5y ago
  Is inspecting stacks used for logging backtraces during instrumentation?
  - 6gvONxR4sf7o 5y ago
    I’ve gotten some great use out of it, personally.
- dehrmann 5y ago
  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.
  - kingmaker 5y ago
    > 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)

by rtpg 5y ago

nine_k 5y ago

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.

nimish 5y ago
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
- _carljm 5y ago
  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.
rtpg 5y ago
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
- nine_k 5y ago
  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.
  - huac 5y ago
    Instagram wrote https://github.com/Instagram/MonkeyType https://github.com/Instagram/MonkeyType to help type their Python code
    - kingmaker 5y ago
      A couple of the folks who wrote MonkeyType (me and _carljm) also work on Cinder :)
  - friendzis 5y ago
    > 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.
    - nine_k 5y ago
      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.
wiml 5y ago
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.
- _carljm 5y ago
  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.
_carljm 5y ago
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.

czardoz 5y ago

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

_ZeD_ 5y ago
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
- czardoz 5y ago
  > 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.
  - throwaway894345 5y ago
    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.

crazypython 5y ago

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.

nitrogen 5y ago
Is inspecting stacks used for logging backtraces during instrumentation?
- 6gvONxR4sf7o 5y ago
  I’ve gotten some great use out of it, personally.
dehrmann 5y ago
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.
- kingmaker 5y ago
  > 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)