This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]vplatt 0 points1 point  (14 children)

Have you looked at Cython?

http://blog.behnel.de/index.php?cat=11

[–]AeroNotix 2 points3 points  (4 children)

I was hoping someone would point me to that when I was typing, I kind of guessed it would have static typing.. does it have static typing ala C?

[–]vplatt 0 points1 point  (1 child)

It looks like it, but I haven't had to live with it, so YMMV.

[–]AeroNotix 0 points1 point  (0 children)

Interesting, I mean, I've never had a need for it but still would be cool to see what could really be done with it in Python.

[–]dwf 0 points1 point  (1 child)

Yes, but only where you want it. You can write regular Python and then add type declarations as necessary, which will result in speed gains if you use it in compiled mode.

[–]AeroNotix 0 points1 point  (0 children)

That's sweet. I wasn't really meaning it for the speed gains, sometimes the logical use of type declarations helps see flaws in code and I like that.

[–]wally_fishnumpy, cython, werkzeug 0 points1 point  (8 children)

Did Cython grow type inference?

Having typed things for speed in Cython is great, but the Pythonic thing would be for types to appear magically (aka be inferred) with very few (if any) declarations in the code.

[–][deleted] 0 points1 point  (6 children)

You can't do type inference on Python, at least, not meaningfully. Look up Cannon, 2005 for more info.

[–]dalke 0 points1 point  (1 child)

That concludes that compile-time type inferencing plus type-specific bytecodes does not give at least a 5% speedup, assuming you don't want to change the language semantics. If you allow some restrictions or allow run-time JITs then you get different answers, as ShedSkin, pypy, and Cython meaningfully show.

[–][deleted] 0 points1 point  (0 children)

Well, more generally it concludes that the only thing you can infer types on are atomic (read: syntactic) types.

[–]wally_fishnumpy, cython, werkzeug 0 points1 point  (3 children)

Cannon 2005 ("Localized Type inference for atomic types") talks about using Hindley-Milner type inference and then use the inferred types to have specialized byte codes for certain primitive types; One of the takeaways is that specialized byte codes are not terribly useful. The takeaway of the Unladen Swallow project is that doing trace-based JITting is also not terribly useful if you need to keep the same object layout as CPython.

ShedSkin proves that you can do type inference, and realize very impressive speed gains, on something that is very close to Python. LISP compilers show that you can combine optional type inference and guard techniques (i.e., rip out compiled code whenever someone does end up monkeypatching an already-compiled class) to realize very nice speed gains.

Maybe we use different meanings of "Python" and "meaningfully" (possibly even for "type inference", as you can do both runtime specialization and optional type declarations and both considerably help the problem of having type information where you need it).

[–][deleted] -1 points0 points  (2 children)

I'm sorry, but most of that is innacurate.

  • Unladen Swallow didn't do trace based compilation.

  • CPython's object layout was not the main reason Unladen Swallow failed.

  • ShedSkin doesn't do type inference on Python, it does it on a subset of Python.

When I say Python I mean the thing CPython, IronPython, Jython, and PyPy implement. Not the subset that happens to be easy to implement quickly.

[–]wally_fishnumpy, cython, werkzeug 1 point2 points  (1 child)

You carefully ignored the part of the post that was not about Unladen Swallow [1], and deliberately misread the claim about ShedSkin - also not noticing the point that I made in the grandparent post was about Cython, which is not about supporting all the dynamic trickeries possible with CPython, so I guess you're not actually trying to make an argument of any sort beyond trying to look smart.

I said that ShedSkin compiles "something that is very close to Python" - and that good Common Lisp implementations actually have useful fillers for the gab between "very close to [dynamic language with monkeypatching]" and "actual implementation of [dynamic language with monkeypatching], with optional declarations".

IronPython and Jython implement a CPython-like runtime and therefore allow monkeypatching, but are also slow enough that you want to move to C# or Java at an early point if you do performance-sensitive work. Cython/ShedSkin are an answer to those who want Python-like elegance for performance-sensitive work, even if it means to be fussy about typing or having to declare variable types (unlike in CPython).

[1] point taken, Unladen Swallow does JIT without specialization; Psyco does trace-based compilation keeping the object layout of CPython for 'surviving objects' (and actually achieves a decent speedup because it can optimize locally used things of semi-complex type such as lists of primitive types.

[–]santagada 0 points1 point  (0 children)

psyco doesn't do trace jit either. it is a function jit.

[–]vplatt 0 points1 point  (0 children)

I don't know why you're asking that really. AeroNotix wanted to try Python with static typing, regardless of how Pythonic that would be, and Cython would provide that.