Revenge of the Types

Of all Armin&#x27;s articles to date, this one I agree the most with.<p>&gt; Python is a language that suffers from not having a language specification ... There are so many quirks and odd little behaviors that the only thing a language specification would ever produce, is a textual description of the CPython interpreter... Keeping a language lean and well defined seems to be very much worth the troubles. Future language designers definitely should not make the mistake that PHP, Python and Ruby did, where the language&#x27;s behavior ends up being &quot;whatever the interpreter does&quot;.<p>This is an incredibly important point. The rise of PyPy is just one compelling illustration of how Python is at a point where a language specification is needed, and these crazy CPython-specific bugs need to be purged.<p>&gt; I think for Python this is very unlikely to ever change at this point, because the time and work required to clean up language and interpreter outweighs the benefits.<p>I would disagree - I think it&#x27;s possible for Python to change this. Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release.

&quot;Because there is basically no type system that fights against you, you are unrestricted in what you can do, which allows you to implement very nice APIs.&quot;<p>If you feel like the type system fights <i>against</i> you, chances are that you are doing something wrong. When I program, the type system definitely fights <i>for</i> me. It gives me a lot of guarantees, plus it&#x27;s a really convenient way of self-documentation. I mean, I&#x27;m not even talking about Haskell or something really sophisticated: I see the advantages even in old plain Java or C++ (so much that, in fact, most of my gripes about Java are about its type system not being complex enough).<p>Also, being &quot;unrestricted&quot; is far from being an universally good thing, since it also means many more opportunities for mistakes. I know for a fact that I make more mistakes in languages without static typing, but well, I guess it&#x27;s just me.

Armin didn&#x27;t address what I belive is the main point of adding type annotations to Python: compiler checkable documentation and as hints to IDE:s. Seen in that perspective, a sucky type system is good enough because it&#x27;s use isn&#x27;t to verify program correctness. Personally, I think a standardized format for describing types in docstrings would be 100x better but that&#x27;s not the way the Python core devs have choosen.<p>Another argument in favor of types is that it will enable Python to optimize code better. But since Python isn&#x27;t built for static typing, the CPython bytecode interpreter has no facilities for exploiting the extra information. And even if it had, the V8 Javascript VM proves that you dont need static types to generate optimized code.

Some people may not understand the context of this part:<p><pre><code> So not long ago someone apparently convinced someone else at a conference that static typing is awesome and should be a language feature. I&#x27;m not exactly sure how that discussion went but the end result was that mypy&#x27;s type module in combination with Python 3&#x27;s annotation syntax were declared to be the gold standard of typing in Python. </code></pre> Ronacher is referring to the fact that Guido van Rossum, the Python language creator and BDFL, recently said he wanted to make mypy&#x27;s type annotation standard into a standard by making use of Python 3 function annotations.<p>The original function annotations standard is PEP-3107[1], GvR&#x27;s proposal is on the python-ideas list[2], and information on mypy can be found at the project&#x27;s site[3].<p>I agree with Ronacher&#x27;s conclusion; I don&#x27;t think static types -- even if only used at runtime -- are a good fit for the language. As for function annotation syntax, I think we just need to admit that isn&#x27;t really good for anything.<p>Great article!<p>[1]: <a href="http://legacy.python.org/dev/peps/pep-3107/" rel="nofollow">http:&#x2F;&#x2F;legacy.python.org&#x2F;dev&#x2F;peps&#x2F;pep-3107&#x2F;</a><p>[2]: <a href="https://mail.python.org/pipermail/python-ideas/2014-August/028618.html" rel="nofollow">https:&#x2F;&#x2F;mail.python.org&#x2F;pipermail&#x2F;python-ideas&#x2F;2014-August&#x2F;0...</a><p>[3]: <a href="http://www.mypy-lang.org/" rel="nofollow">http:&#x2F;&#x2F;www.mypy-lang.org&#x2F;</a>

I&#x27;ve been using Nimrod to replace Python on a Bitcoin project.<p>elliptic.nim: <a href="https://github.com/def-/bigints/blob/master/examples/elliptic.nim" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;def-&#x2F;bigints&#x2F;blob&#x2F;master&#x2F;examples&#x2F;ellipti...</a><p>elliptic.py: <a href="https://github.com/wobine/blackboard101/blob/master/EllipticCurvesPart4-PrivateKeyToPublicKey.py" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wobine&#x2F;blackboard101&#x2F;blob&#x2F;master&#x2F;Elliptic...</a><p>Nimrod looks and feels like python, but it compiles to C. It&#x27;s like C except with Pythonic syntax and with Boehm GC optional. In addition, Nimrod has a burgeoning NPM-like module ecosystem developing, albeit in the early stages.<p><pre><code> import rdstdin, strutils let time24 = readLineFromStdin(&quot;Enter a 24-hour time: &quot;).split(&#x27;:&#x27;).map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, &quot;8:00 a.m.&quot;, &quot;10:16 a.m.&quot;), (583, &quot;9:43 a.m.&quot;, &quot;11:52 a.m.&quot;), (679, &quot;11:19 a.m.&quot;, &quot;1:31 p.m.&quot;), (767, &quot;12:47 p.m.&quot;, &quot;3:00 p.m.&quot;), (840, &quot;2:00 p.m.&quot;, &quot;4:08 p.m.&quot;), (945, &quot;3:45 p.m.&quot;, &quot;5:55 p.m.&quot;), (1140, &quot;7:00 p.m.&quot;, &quot;9:20 p.m.&quot;), (1305, &quot;9:45 p.m.&quot;, &quot;11:58 p.m.&quot;)] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. &lt;flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo &quot;Closest departure time is &quot;, flights[getClosest()].depart, &quot;, arriving at &quot;, flights[getClosest()].arrive</code></pre>

Random question for the type experts out there: is there any language that lets me track the units of my numeric variables? For instance, something like this:<p><pre><code> float&lt;km&gt; drop(float&lt;m&gt; x0, float&lt;s&gt; duration) { float&lt;m&gt; x = x0; float&lt;s&gt; t = 0; float&lt;m&#x2F;s&gt; v = 0; float&lt;m&#x2F;s^2&gt; g = -10; float&lt;s&gt; dt = 0.01; while (t &lt; duration) { v += g*dt; x += v*dt; t += dt; } return x * (1&lt;km&gt;&#x2F;1000&lt;m&gt;); &#x2F;&#x2F; abbrev for a cast: (float&lt;km&#x2F;m&gt;).001 } </code></pre> Then I want the compiler to check that I&#x27;m not mixing up my units. It seems like this would be really useful, but I&#x27;ve never seen it before.

We live in that wonderfull time in development,where a lot of things are questioned.A lot of languages that used to rule everywhere are questioned,like the OP,and devs try to come up with the ultimate language that would solve every use case.<p>There is,of course, no such a language but future languages wether they are dynamic or static ,strong or weak (type wise) will certainly not make the same mistake as their ancestors.<p>Personally I want a scripting language,with type inference but real strong static typing, that can be easily interfaced with C++, that handles concurrency the right way(ie not like javascript callbacks),that is trully multipurpose(like python) elegant(a bit like ruby), 00 with composition and strong encapsulation in mind and access modifiers, with immutable structures and variables by default but not limited to it,with some functional features without looking like Haskell,resonably fast for GUI dev,scientif computation and non trivial web apps,easy to deploy on a server, with sane error handling,IO streams everywhere, a clear syntax(no unreachable characters on non english keyboards everywhere),with a good package manager, an interactive repl(like IPython or the tool for swift,I forgot the name) and with battery included.<p>So we are definetly living in an exciting period.

The argument seems to be that if the added type system is not perfect, then it will be useless. For a working counterexample, see the Closure Compiler (<a href="https://github.com/google/closure-compiler" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;closure-compiler</a>), which adds a bolt-on, underspecified, occasionally-changing type system to Javascript. Similarly to GvR&#x27;s proposal (<a href="https://mail.python.org/pipermail/python-ideas/2014-August/028618.html" rel="nofollow">https:&#x2F;&#x2F;mail.python.org&#x2F;pipermail&#x2F;python-ideas&#x2F;2014-August&#x2F;0...</a>), the types are only ever checked at compile time: there&#x27;s no attempt to use them as runtime assertions and very limited attempts to use them for compile-time improvements. So, yes, because they are imperfect and optional, you don&#x27;t catch every type error, and you need to add type hints &#x2F; casts that in a perfect system wouldn&#x27;t be necessary.<p>Is this kind of flawed type system worth it? Hell yes. I&#x27;ve maintained large programs in both Python and (closure-compiled) Javascript, and with the former I&#x27;ve wished I had the help of the limited type checking available in the latter.

If you want to learn more about how &#x27;optional&#x27; and &#x27;unsound&#x27; type systems can still deliver a lot of value there are some interesting articles on Dart&#x27;s optional types:<p>* <a href="http://journal.stuffwithstuff.com/2011/10/21/wrapping-my-head-around-optional-typing/" rel="nofollow">http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2011&#x2F;10&#x2F;21&#x2F;wrapping-my-hea...</a><p>* <a href="https://www.dartlang.org/articles/why-dart-types/" rel="nofollow">https:&#x2F;&#x2F;www.dartlang.org&#x2F;articles&#x2F;why-dart-types&#x2F;</a><p>* <a href="https://www.dartlang.org/articles/optional-types/" rel="nofollow">https:&#x2F;&#x2F;www.dartlang.org&#x2F;articles&#x2F;optional-types&#x2F;</a>

I find it interesting that this is exactly what Perl6 tried to handle gracefully, both on the technical side (a type system that supports both static and dynamic typing) as well as on the practical side (a re-implementation from scratch with some measure of interoperability).<p>However, they did not set out to just design the next version of Perl, but the <i>last</i> version, reasoning that if you have proper extension mechanism in place, you won&#x27;t have to do a reboot ever again.<p>This resulted in gradual typing (which sometimes needs to fall-back to runtime checks), a pluggable syntax with extensible grammar, a flexible meta-object protocol, default numeric types that are objects (rationals or bigints), lazy list, reified language construct (variables as container objects) and other stuff that makes a straight-forward implementation horribly slow.

Not only that, but look at the niche Python is occupying. It&#x27;s a well established and respected niche to which, by definition, the language is suited very well.<p>By adding static types, the focus of the language would move to a different niche, which would probably be already occupied by some competitor language(s) which do(es) types much better.<p>If you want sort-of Python-ish syntax with elaborate types, just use Nimrod and leave Python alone. Get the right tool for the job, don&#x27;t mutilate a perfectly good existing tool.

Hrm. I think this article does a great job of explaining weird inconsistencies in Python&#x27;s current type system, but I think it does a somewhat less good job of demonstrating that adding annotations is actively harmful. What would be some examples of situations where inconsistencies in the type system made annotations problematic in practice? Are those situations compelling enough to warrant not adding <i>any</i> annotations to the language?

Python&#x27;s API structure may be fast and loose, but that is a feature, I think. Its type system may have some threadbare implementation spots – the _sre example from the standard library, for instance – but there are some compelling examples as well.<p>I, for one, have been working on an app implemented mostly with PyObjC, the bridge between Python and Objective-C. I had all but written off PyObjC as a bizarre yet unuseful language mule... but lately I had the occasion to read through the PyObjC source code base, in service of my project. Did you know that when you subclass a wrapped Objective-C type in Python, an all-new Objective-C class is created and wrapped as the descendant class, behind the scenes? That blew my mind.<p>That happens transparently, in concordance with Python&#x27;s type heiarchy and runtime ABI. As it turns out, PyObjC predates Mac OS X, and the authors have put a lot of work into mitigating things like the GIL and system events.<p>I am also a fan of Django&#x27;s field type system, as the author mentioned – and I am curious about what he thinks about descriptors (which he mentioned one but did not address) – I think descriptors are an amazing addition to the duck-typing regime in Pythonville.

Lua<p>The more I read Armin&#x27;s posts, the more I believe he should switch to Lua. It has all the core features he wants:<p>- simple design<p>- fast<p>- consistent behavior<p>In addition to what&#x27;s mentioned above, LuaJIT is a marvelously designed JIT (please donate to the project [1]. Let&#x27;s keep allowing Mike Pall to have a livelihood)<p>[1] <a href="http://luajit.org/sponsors.html" rel="nofollow">http:&#x2F;&#x2F;luajit.org&#x2F;sponsors.html</a>

This is a very nice article showing some of the issues troubling python and the proposed type anotations.<p>I would summarize my view of the type annotation proposal as follows: Statically typed languages can introduce inference heuristics that minimize the amount of type declarations. They can &quot;jump&quot; into the dynamically typed world more easily. The other way around is a lot harder. Not only are all those type annotations lacking in the standard library and the tools around, but there is also a lack of function design by types.

Can somebody explain in greater detail what this means:<p>&gt; This is true for the CPython interpreter world, but not true for Python the language. That these are not the same things is disappointing but generally the case.<p>My understanding was that the CPython interpreter is considered the &quot;reference&quot; implementation of Python, and that (except for bugs) it defined Correct Behavior for Python-the-language.

If the author is reading this thread, I spotted this type-o:<p><pre><code> Type type claims that it&#x27;s a subclass of object.</code></pre>

My hope is that Guido&#x27;s plan to incorporate the type declaration module (`types`, a subcomponent of mypy) will encourage the Python team to clean up the issues brought up in TFA.

I didn&#x27;t know Python users hate static typing so much.

&gt;So what&#x27;s the solution? Not having null references and having explicitly typed arrays.<p>Throwing the baby out with the bath water. Null types are extremely useful.<p>I don&#x27;t get why the author claims the null type in C# is a form of &quot;damage&quot;. It&#x27;s just said that it&#x27;s bad, not why. The problem with None in python was that you can&#x27;t tell what it&#x27;s supposed to be. In C# you know what type the null is meant to be.