7 ms·

I mostly like Python for its clean syntax but the examples contained in this PEP turn unreadable really fast. I don't look forward to this and I don't really se

by CrLf 11y ago

I mostly like Python for its clean syntax but the examples contained in this PEP turn unreadable really fast. I don't look forward to this and I don't really see the point of it. I can see how it can be useful in theory but, in practice, I just see a symptom of language bloat. The way I see it, if you find yourself in the situation where explicit type checking is important, there's probably something wrong with your process or team. Either your are not testing properly, or your team's mindset is more adjusted to another language. The danger I see with this becoming widespread is Python becoming somewhat like C++ where it's very easy to come across code one can't easily read because it uses a different subset of features than you're used to. This sort of "language accents" so common in human languages is something that should be avoided in computer languages, IMHO.

jghn 11y ago
One could argue that you'd need many fewer lines of test code if your compiler can prove a lot of stuff is correct at compile time. It's a personal preference thing but I prefer this situation and don't view it as having poor testing
- prodigal_erik 11y ago
  This. Every test just explores one special case of the invariant I would prefer to enforce but cannot with today's tooling.
coldnebo 11y ago
It seems more like Scala syntax, which is much cleaner than C++ IMHO. But with Java becoming dynamic (and C++ techniques for same), is the future a smear of shared language features, like Bladerunner's cityspeak, or are these just intermediate forms as a new protolanguage capable of unifying these features comes into existence?
- jghn 11y ago
  I suspect the latter. The static typing crowd is moving towards type inference - you mentioned the obvious examples already. Now we're seeing dynamic languages evolving towards static typing with inference. I think that most people if they really think deeply about it would say that all things being equal that static typing is a good thing. The problem is that all things are not equal and that the cost of extra syntax, boilerplate, etc can completely outweigh the benefits of of that static typing (as the GP post clearly believes). I was a huge dynamic language fan until I started using Scala full time and since then I've gone completely the other direction to being a static fan. I suspect as more people start finding their way to tools which provide static typing guarantees without the syntax getting in their way so much that we'll find a nice middle ground.
ilevkivskyi 11y ago
From the acceptance letter: """ if you are worried that this will make Python ugly and turn it into some sort of inferior Java, then I share you concerns, but I would like to remind you of another potential ugliness; operator overloading. C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce "concise" (a.k.a. line noise) code. Python also has operator overloading and it is used sensibly, as it should be. Why? It's a cultural issue; readability matters. Python is your language, please use type-hints responsibly :) """ I would add metaclasses, generators, etc. all these are already enough to write horrible things. It is indeed all about "culture", readability is really the cornerstone of Python culture. Type hints when used responsibly are fantastic tool. You could be surprised but they really improve readability, it's like a succinct docstring. I discovered this while recently reading through one large codebase. Moreover, typechecker will tell you when your "docs" do not reflect actual semantics. Finally, I would like to point out that typing.py and Mypy are pure Python, no magic :-) At the same time "import typing" is very in the spirit of "import antigravity". I hope Python gradual typing could become alternative to Java/C++/etc. BDSM-style typing and one day we could say: "Come join us! Typing is fun again" :-)
- kbenson 11y ago
  > C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce "concise" (a.k.a. line noise) code. That's fairly funny coming from a discussion about a language that overloads '+' for strings and numerics, and overloads ==/!= similarly. Perl uses '.' for string concatenation and '+' for numeric addition, and uses eq/ne for string equality, and ==/!= for numeric equality. There's a reason for that. Overloading is not necessarily used that often in Perl. It's a module that's part of the core, but it's fairly clunky and I rarely see it in the wild except for that spots that it really makes sense (DateTime object boolean comparison comes to mind).

by CrLf 11y ago

jghn 11y ago

One could argue that you'd need many fewer lines of test code if your compiler can prove a lot of stuff is correct at compile time. It's a personal preference thing but I prefer this situation and don't view it as having poor testing

prodigal_erik 11y ago
This. Every test just explores one special case of the invariant I would prefer to enforce but cannot with today's tooling.

coldnebo 11y ago

It seems more like Scala syntax, which is much cleaner than C++ IMHO. But with Java becoming dynamic (and C++ techniques for same), is the future a smear of shared language features, like Bladerunner's cityspeak, or are these just intermediate forms as a new protolanguage capable of unifying these features comes into existence?

jghn 11y ago
I suspect the latter. The static typing crowd is moving towards type inference - you mentioned the obvious examples already. Now we're seeing dynamic languages evolving towards static typing with inference. I think that most people if they really think deeply about it would say that all things being equal that static typing is a good thing. The problem is that all things are not equal and that the cost of extra syntax, boilerplate, etc can completely outweigh the benefits of of that static typing (as the GP post clearly believes). I was a huge dynamic language fan until I started using Scala full time and since then I've gone completely the other direction to being a static fan. I suspect as more people start finding their way to tools which provide static typing guarantees without the syntax getting in their way so much that we'll find a nice middle ground.

ilevkivskyi 11y ago

From the acceptance letter: """ if you are worried that this will make Python ugly and turn it into some sort of inferior Java, then I share you concerns, but I would like to remind you of another potential ugliness; operator overloading. C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce "concise" (a.k.a. line noise) code. Python also has operator overloading and it is used sensibly, as it should be. Why? It's a cultural issue; readability matters. Python is your language, please use type-hints responsibly :) """ I would add metaclasses, generators, etc. all these are already enough to write horrible things. It is indeed all about "culture", readability is really the cornerstone of Python culture. Type hints when used responsibly are fantastic tool. You could be surprised but they really improve readability, it's like a succinct docstring. I discovered this while recently reading through one large codebase. Moreover, typechecker will tell you when your "docs" do not reflect actual semantics. Finally, I would like to point out that typing.py and Mypy are pure Python, no magic :-) At the same time "import typing" is very in the spirit of "import antigravity". I hope Python gradual typing could become alternative to Java/C++/etc. BDSM-style typing and one day we could say: "Come join us! Typing is fun again" :-)

kbenson 11y ago
> C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce "concise" (a.k.a. line noise) code. That's fairly funny coming from a discussion about a language that overloads '+' for strings and numerics, and overloads ==/!= similarly. Perl uses '.' for string concatenation and '+' for numeric addition, and uses eq/ne for string equality, and ==/!= for numeric equality. There's a reason for that. Overloading is not necessarily used that often in Perl. It's a module that's part of the core, but it's fairly clunky and I rarely see it in the wild except for that spots that it really makes sense (DateTime object boolean comparison comes to mind).