3 ms·

...and so we risk shuffling even further away from what made Python great. Simple pragmatism. Now in addition to unicode hair tearout, xrange forcefeed, dict ac

...and so we risk shuffling even further away from what made Python great. Simple pragmatism. Now in addition to unicode hair tearout, xrange forcefeed, dict access strait jacket, print function dogmatism, and extraneous unused async library which was already implemented 14x elsewhere, we are moving towards strictly typed Python?? If you want all this stuff, surely there is C, Ocaml, Go, or Typescript, etc, all of which are much faster?

protomikron 10y ago
It is a common misconception that typing makes stuff more complicated and inconvenient. Some type systems are quiet bad (not powerful enough, so they do more harm than good), but that does not mean that the idea of typing itself is bad, but their implementation is. In my opinion Python kicks ass, because of world-class libraries for nearly anything, and not because it's dynamic (a broad term, I would say it's strongly typed) und you do not have to declare types (which can often be inferred). You listed 4 specific languages, but the following things are each inconvenient in them: - C: it's inconvenient to implement a quick prototype - Ocaml: it's inconvenient that the stdlib is so small - Go: it's inconvenient for scientific/numerical code - TypeScript: it's inconvenient to run server-side Obviously you can do everything in any language (Turing, blabla), but the question is, how much effort (time) does it cost. Python rocks in all of them (edit: the big exception being frontend webdev), in particular for quick prototyping. I think mypy is an exceptional and fine contribution to the eco-system and I really appreciate their effort.
- llekn 10y ago
  Being in the middle of a struggle with Javascript tooling (Javascript, ES5 v/s ES6, typescript, webpack v/s System.js, shims, pollyfils, npm downloading the internet, etc, etc) I can't but imagine that there should be a better way. How much I would like Webassembly to be ready to open the gates to other languages on the frontend land. Anyone here has more information about webassembly / python on the browser? I would love to know what is the current state of the art of running python on the browser and contribute to make the dream come true. I have on my radar Brython [0], py.js [1](seems to be abandoned) and pypy.js [2] [0] http://www.brython.info/ http://www.brython.info/ [1] http://pyjs.org/ http://pyjs.org/ [2] http://pypyjs.org/ http://pypyjs.org/
  - aumerle 10y ago
    https://github.com/kovidgoyal/rapydscript-ng https://github.com/kovidgoyal/rapydscript-ng https://github.com/QQuick/Transcrypt https://github.com/QQuick/Transcrypt
- DanRosenwasser 10y ago
  Why exactly is TypeScript inconvenient on the server-side?
nchammas 10y ago
> we are moving towards strictly typed Python I don't know what "strictly typed Python" is, but the type checking discussed in this post is 1) completely optional and 2) static. You don't have to do it if you don't want to, and even if you do do it, it doesn't affect in any way Python's runtime behavior or flexibility. You can have a codebase that works fine yet at the same time fails mypy's checks. Also, no, we are not moving towards "strictly typed Python", even if that were a thing. PEP 484, which laid out the standard type hints, included this line in bold under "Non-goals" [0]: > It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention. [0] https://www.python.org/dev/peps/pep-0484/#non-goals https://www.python.org/dev/peps/pep-0484/#non-goals
takeda 10y ago
This is optional, and the main benefit of this is to find bugs in the code. It especially helps to port code from Python 2 to Python 3. I used typing with PyCharm for one of my project and it helped me to find several bugs.

protomikron 10y ago

It is a common misconception that typing makes stuff more complicated and inconvenient. Some type systems are quiet bad (not powerful enough, so they do more harm than good), but that does not mean that the idea of typing itself is bad, but their implementation is. In my opinion Python kicks ass, because of world-class libraries for nearly anything, and not because it's dynamic (a broad term, I would say it's strongly typed) und you do not have to declare types (which can often be inferred). You listed 4 specific languages, but the following things are each inconvenient in them: - C: it's inconvenient to implement a quick prototype - Ocaml: it's inconvenient that the stdlib is so small - Go: it's inconvenient for scientific/numerical code - TypeScript: it's inconvenient to run server-side Obviously you can do everything in any language (Turing, blabla), but the question is, how much effort (time) does it cost. Python rocks in all of them (edit: the big exception being frontend webdev), in particular for quick prototyping. I think mypy is an exceptional and fine contribution to the eco-system and I really appreciate their effort.

llekn 10y ago
Being in the middle of a struggle with Javascript tooling (Javascript, ES5 v/s ES6, typescript, webpack v/s System.js, shims, pollyfils, npm downloading the internet, etc, etc) I can't but imagine that there should be a better way. How much I would like Webassembly to be ready to open the gates to other languages on the frontend land. Anyone here has more information about webassembly / python on the browser? I would love to know what is the current state of the art of running python on the browser and contribute to make the dream come true. I have on my radar Brython [0], py.js [1](seems to be abandoned) and pypy.js [2] [0] http://www.brython.info/ http://www.brython.info/ [1] http://pyjs.org/ http://pyjs.org/ [2] http://pypyjs.org/ http://pypyjs.org/
- aumerle 10y ago
  https://github.com/kovidgoyal/rapydscript-ng https://github.com/kovidgoyal/rapydscript-ng https://github.com/QQuick/Transcrypt https://github.com/QQuick/Transcrypt
DanRosenwasser 10y ago
Why exactly is TypeScript inconvenient on the server-side?

nchammas 10y ago

> we are moving towards strictly typed Python I don't know what "strictly typed Python" is, but the type checking discussed in this post is 1) completely optional and 2) static. You don't have to do it if you don't want to, and even if you do do it, it doesn't affect in any way Python's runtime behavior or flexibility. You can have a codebase that works fine yet at the same time fails mypy's checks. Also, no, we are not moving towards "strictly typed Python", even if that were a thing. PEP 484, which laid out the standard type hints, included this line in bold under "Non-goals" [0]: > It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention. [0] https://www.python.org/dev/peps/pep-0484/#non-goals https://www.python.org/dev/peps/pep-0484/#non-goals

takeda 10y ago

This is optional, and the main benefit of this is to find bugs in the code. It especially helps to port code from Python 2 to Python 3. I used typing with PyCharm for one of my project and it helped me to find several bugs.