Mypy - An experimental Python variant with dynamic and static typing

why doesn't this use the python standard for adding type information? it should be:<p><pre><code> def foo(n: int): </code></pre> not<p><pre><code> def foo(int n): </code></pre> then it would be valid python 3 code (and would also work with pytyp (disclaimer: mine)).<p><a href="http://docs.python.org/py3k/reference/compound_stmts.html#function-definitions" rel="nofollow">http://docs.python.org/py3k/reference/compound_stmts.html#fu...</a> <a href="http://www.python.org/dev/peps/pep-3107/" rel="nofollow">http://www.python.org/dev/peps/pep-3107/</a> <a href="http://www.acooke.org/pytyp/" rel="nofollow">http://www.acooke.org/pytyp/</a>

<p><pre><code> &#62; Mypy will get rid of the Global Interpreter Lock (GIL) &#62;Details of the concurrency model are still undecided, though </code></pre> Wait, what? There have been numerous attempts to get rid of the GIL, most of which failed miserably. A promise to get rid of the GIL without even deciding on a concurrency model seems a little premature.

From the FAQ:<p><i>The initial compiler will compile into C or use LLVM for the back end</i><p>This is .. a rather fundamental point. More critically, there is no link that I could see to any code.<p>It is an interesting idea, but it seems a little too under-cooked to merit much discussion right now. However, one way that this could get really good traction is if it were to support Cython code (which doesn't seem to be the case, from the FAQ)

How will mypy give satisfactory array and integer performance? In the case of arrays, unless they are homogeneous, you have to implement them as arrays of objects. And in the case of integers, they won't have the Python semantics unless they are the same number of bits as Python integers.<p>Also, what about things like metaclasses, changing methods of classes at runtime, etc? It seems like it won't be much like Python at all, and certainly not compatible, if it is to be efficient!<p>It seems to me that Python is fundamentally dynamic in nature, not just programatically, but also in terms of its type system.<p>Cobra was an attempt at a Python-like language with static compilation and type annotation. But so far, I don't see a mass exodus from Python to Cobra.<p>If mypy isn't going to be fully Python compatible, why wouldn't people who were unhappy with Python just switch to another statically typed/compiled language that already exists?

As much as I'd like to believe that there is a Python interpreter without a GIL, type inference, and LLVM backend that can support the full standard library I'm doubtful until I see evidence.

I've been thinking about this for a while: the benefit of static typing doesn't really come from being compile-time, it comes from making sure the causes of a certain category of errors must be local to the function where the error's seen. I suspect that a run-time static typing framework, which simply did the equivalent of asserting the type of any variable whenever it was assigned, would provide almost all of the safety/development advantages of compile-time typing, and be much easier to implement for python.<p>Has anything like this been attempted?

An interesting idea. I do like Python's syntax - it's how I indent my C code so it's quite natural. Having to hit backspace is a bit annoying though when you're used to the IDE auto inserting a } you can down-arrow over.<p>Personally I'd prefer explicit dynamic types and implicit type inference, but that's a personal preference. From working with C# and F# in my day job, F# is much more graceful without the 'var' everywhere that you get with C#'s inference.

Reminds me a bit of Julia[1], which allows optional static typing.<p>[1] <a href="http://julialang.org/" rel="nofollow">http://julialang.org/</a>

It looks like they could've chosen to extend one of the established projects (e.g. Cython, PyPy, CPython), maybe making some compromises. Instead they chose to start from scratch, which means that the chances of this actually becoming usable are.. Rather slim. What a pity. The Python community could really use something like this.

What about "hints"?<p><pre><code> def foo( often int n ): </code></pre> This one would generate both the dynamic &#38; the static versions.<p>Once all call sites stop using the dynamic version, one can move on to strict typing (and remove the "often" qualifier), if such is the goal.<p>Think of it like the old "register" hint in C code (now obsolete).

&#62; dynamic (or "duck") typing<p>Nit-pick: This post seem to say the dynamic typing and duck typing are the same thing. They're not. Duck-typing means looking up method names runtime by name, and not compile time by interface. Dynamic typing is a much bigger concept.

Mypy itself may be vaporware at the moment, but it's the successor to an existing language which has been in development for several years- <a href="http://www.alorelang.org/" rel="nofollow">http://www.alorelang.org/</a>

Whats the benefits of this over cython?

Boo, Shed-skin