Since you're after micro-controllers you might be interested in Nim. At this year's FOSDEM we showed off some micro-controllers running Nim code[1]. The language is definitely less Python-like than Cython, but it might just be similar enough for your use cases (I started using Nim as a Python replacement).
For people who don't want to bounce through twitter to get to the home page:
Re:Python startup time: milliseconds matter
by quotemstr on Wednesday May 02, 2018 @04:09PM
(#16980728)
Unless your Python compiler can use cpython modules without a massive performance penalty, it's going to see very limited adoption. The ecosystem matters.
Re:Python startup time: milliseconds matter
by sitkack on Wednesday May 02, 2018 @05:34PM
(#16981348)
We had a chance with ctypes and now CFFI to move away from the platform calcifying cpython module interface that is overly coupled to the cpython runtime. I am very disappointed in the lack of affordances that cpython gives to alternative pythons to support their work. The stdlib is a crufty mess that is overly coupled to cpython as well. The batteries are corroded and need to be swapped out for a modular pack.
Re:Python startup time: milliseconds matter
by Rotareti on Wednesday May 02, 2018 @05:06PM
(#16981161)
I don't think it would be hard to add type annotations to existing projects, though. Something similar happened in the JS world with the transition of JS projects to TypeScript and it wasn't a big deal, IIRC.
Re:Python startup time: milliseconds matter
by Thrymr on Wednesday May 02, 2018 @04:09PM
(#16980729)
> I'm so longing for a Python(like) compiler.
There is Cython, of course, which is a great python (+) compiler. I assume you mean a just-in-time compiler as opposed to a static compiler.
Re:Python startup time: milliseconds matter
by turbinerneiter on Wednesday May 02, 2018 @04:52PM
(#16981054)
No. Pypy already does JIT.
And Cython has the speed, but not the size.
The target of my phantasy compiler are microcontrollers. That's why the (correct) comment of quotemstr isn't that big of a concern to me.
Re:Python startup time: milliseconds matter
by blattimwind on Wednesday May 02, 2018 @05:35PM
(#16981355)
Just throwing Python code at Cython doesn't really improve performance all that dramatically, because it'll be doing pretty much the same thing as the bytecode interpreter, except that all the saucy special-cases are now unrolled many times across all code.
Re:Python startup time: milliseconds matter
by Delgan on Wednesday May 02, 2018 @04:53PM
(#16981061)
Isn't it what Numba does quite successfully for a subset of Python?
Re:Python startup time: milliseconds matter
by turbinerneiter on Wednesday May 02, 2018 @05:04PM
(#16981140)
Not static AOT, not creating tiny binaries that fit on a microcontroller.
There is a lot of stuff out there that goes in this direction. There is nukita (again no small binaries), there is even an abandoned GCC frontend that can compile some minimal examples, but has been abandoned long ago.
Seriously, the time I spent researching this topic - if a proper compiler engineer would spend that on the actual compiler, it'd be done by now.
Re:Python startup time: milliseconds matter
by joejev on Wednesday May 02, 2018 @05:30PM
(#16981312)
You must work fast: https://numba.pydata.org/numba-doc/dev/user/pycc.html
MicroPython put together a Python in 250kb. Why the hell can't we make an LLVM frontend for Python that can use type hints for optimization? Sure, you lose some dynamic features as you optimize for speed, but that's the dream. Quickly write a prototype, not caring about types, optimize later with adding types and removing dynamicism.
I'm currently learning Racket and LLVM and I have about 70 more years to live. I'm gonna try make Python fast on slow weekends 'til I die.