Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 0484 – Type Hints is accepted

python.org

Post reply on HN
Print view View original

71–75 of 75 posts

Re: PEP 0484 – Type Hints is accepted

#71

Post by rtpg »

rnnr wrote: post #44
rtpg wrote: post #43

Earlier quoted context omitted.

I think it's always been about how annoying it is to write out types. If you look at how popular go is among pythonistas, it kind of shows that the issue was really a lack of type inference more than anything else.

I share the same opinion, even sth as simple as TI makes things so much better. It's not only about writing but also reading the code. A good summary what's wrong with the type systems of the java era: http://www.slideshare.net/ScottWlaschin/c-light

what a great presentation, very powerful stuff

Re: PEP 0484 – Type Hints is accepted

#72

Post by ubernostrum »

cma wrote: post #67
ubernostrum wrote: post #60

Earlier quoted context omitted.

Nitpick: this isn't an implicit conversion. There's a lot of history of languages without a real boolean type using integer 0 and 1 as the sentinel values indicating false-ness and true-ness. And Python, in a nod to that, implements bool as a subclass of int, of which only two instances can ever exist (with False having a value of 0 and True having a value of 1). So this isn't weak typing -- isinstance(True, int) is…

Interesting, so technically isn't weak typing, but in practice to me it is a distinction without a difference. You could make int a subtype of string, and allow things like "1" + 1 == "11" and end up with many of the same problems of weakly typed languages.

Well, there's also ancient-history stuff going on here in that Python originally didn't have a boolean type, which mean using integer 0 and 1 was the standard practice. "True" and "False" as aliases for integer 1 and 0 were added in 2002, and the actual boolean type -- implemented as a subclass of int since that got automatic compatibility with existing code using integer values -- was added in 2003.

Re: PEP 0484 – Type Hints is accepted

#73

Post by Veedrac »

cma wrote: post #67
ubernostrum wrote: post #60

Earlier quoted context omitted.

Nitpick: this isn't an implicit conversion. There's a lot of history of languages without a real boolean type using integer 0 and 1 as the sentinel values indicating false-ness and true-ness. And Python, in a nod to that, implements bool as a subclass of int, of which only two instances can ever exist (with False having a value of 0 and True having a value of 1). So this isn't weak typing -- isinstance(True, int) is…

Interesting, so technically isn't weak typing, but in practice to me it is a distinction without a difference. You could make int a subtype of string, and allow things like "1" + 1 == "11" and end up with many of the same problems of weakly typed languages.

Well, that would violate the Liskov Substitution Principle.

But I think there's a fundamental divide about what weak typing actually is. For example, it's entirely possible in Rust to have implemented Add for i32 and String. Even this isn't weak typing in its traditional form.

AFAIK, in this sense weak typing refers to whenever the compiler will implicitly cast one type to another in order to satisfy a type constraint. C's number types do this. PHP does this on everything. Javascript has, eg., [] + [] == "". Python does not do this - all type casts are explicit in the implementation of the operator or function (which is implemented on the type, not globally).

It's reasonable to argue that the use of the phrase "weak typing" to mean "things I don't like about a type-system" is not only well established but maybe even more useful. It does, however, irritate Python programmers who don't want their language lumped in with PHP.

Re: PEP 0484 – Type Hints is accepted

#74

Post by ilevkivskyi »

CrLf wrote: post #59

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…

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" :-)

Re: PEP 0484 – Type Hints is accepted

#75

Post by kbenson »

ilevkivskyi wrote: post #74
CrLf wrote: post #59

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…

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 use…

> 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).

Post reply on HN