5 ms·

> I gave a presentation back in 2013 at mloc.js where I argued that static typing is an essential feature when picking a language for a large software project

> I gave a presentation back in 2013 at mloc.js where I argued that static typing is an essential feature when picking a language for a large software project OK, so you went shopping for a statically typed language and somehow ended up with Python (which only _just_ started having annotations in 3.6)? Why not pick any of the multitudes of languages that actually do have static type-checking?

meddlepal 10y ago
I wonder if author confused static with strongly typed?
- drodgers 10y ago
  Python was already strongly typed; the new type annotations just allow it to be explicitly typed too.
ubernostrum 10y ago
which only _just_ started having annotations in 3.6 This is incorrect. Python gained syntactic support for annotations of functions and methods in 3.0. It was anticipated that this feature would be used to annotate types of arguments and return values, but nothing about it required using it for this purpose (and in fact, nothing requires using it for that purpose today). Python 3.5 added the 'typing' module to the standard library (and it was also released standalone on the Python Package Index, allowing it to be installed on older versions of Python). This module provides a standardized way to describe types, and an ecosystem of tools has popped up which make use of the typing module's approach to perform static-style type checking of Python source code. Python 3.6 added syntax for annotating variables, and for declaring variables without assigning a value to them. Prior to this, type-checking tools used type-declaring comments to read the types of variables. Also, note that the annotations -- which are correctly termed "type hints" when used to describe types -- result in no enforcement whatsoever on the part of the Python runtime, which does not assign any special meaning to annotations, and aside from exposing them via an introspectable attribute will not do anything with them either prior to or during execution. To use them for type-checking purposes, you must install and run a third-party tool which reads the annotations and compares them to actual usage in the code.
- azag0 10y ago
  ad the last point: Isn't this perfectly fine in principle (minus the fact that Mypy is third-party)? Compilers in static languages also work only with the source code, in a way, as there is no runtime interpreter. So there should be no reason for type checkers on dynamic languages to require the runtime. Granted, this forces you to essentially write type-statically in a dynamic language, which might limit your expressiveness, but that's probably your point anyway if you do type checking. Now I'm not saying that Mypy is anywhere near this hypothetical situation. My point is that type checkers over dynamic languages should not need the runtime in principle. Conversely, the runtime should not need to do the type checking, for performance.
  - ubernostrum 10y ago
    Many people, when they hear "static types for Python", expect that the Python interpreter would perform some kind of pre-execution step of checking types and usage, and refuse to execute code with type errors. Since this is not the case (and would be difficult/impossible to implement given that Python code can import new modules at any time, and also change the import paths), it's worth pointing out.

meddlepal 10y ago

I wonder if author confused static with strongly typed?

drodgers 10y ago
Python was already strongly typed; the new type annotations just allow it to be explicitly typed too.

ubernostrum 10y ago

which only _just_ started having annotations in 3.6 This is incorrect. Python gained syntactic support for annotations of functions and methods in 3.0. It was anticipated that this feature would be used to annotate types of arguments and return values, but nothing about it required using it for this purpose (and in fact, nothing requires using it for that purpose today). Python 3.5 added the 'typing' module to the standard library (and it was also released standalone on the Python Package Index, allowing it to be installed on older versions of Python). This module provides a standardized way to describe types, and an ecosystem of tools has popped up which make use of the typing module's approach to perform static-style type checking of Python source code. Python 3.6 added syntax for annotating variables, and for declaring variables without assigning a value to them. Prior to this, type-checking tools used type-declaring comments to read the types of variables. Also, note that the annotations -- which are correctly termed "type hints" when used to describe types -- result in no enforcement whatsoever on the part of the Python runtime, which does not assign any special meaning to annotations, and aside from exposing them via an introspectable attribute will not do anything with them either prior to or during execution. To use them for type-checking purposes, you must install and run a third-party tool which reads the annotations and compares them to actual usage in the code.

azag0 10y ago
ad the last point: Isn't this perfectly fine in principle (minus the fact that Mypy is third-party)? Compilers in static languages also work only with the source code, in a way, as there is no runtime interpreter. So there should be no reason for type checkers on dynamic languages to require the runtime. Granted, this forces you to essentially write type-statically in a dynamic language, which might limit your expressiveness, but that's probably your point anyway if you do type checking. Now I'm not saying that Mypy is anywhere near this hypothetical situation. My point is that type checkers over dynamic languages should not need the runtime in principle. Conversely, the runtime should not need to do the type checking, for performance.
- ubernostrum 10y ago
  Many people, when they hear "static types for Python", expect that the Python interpreter would perform some kind of pre-execution step of checking types and usage, and refuse to execute code with type errors. Since this is not the case (and would be difficult/impossible to implement given that Python code can import new modules at any time, and also change the import paths), it's worth pointing out.