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

61–70 of 75 posts

Re: PEP 0484 – Type Hints is accepted

#61

Post by ubernostrum »

aapycgarb wrote: post #33
dangirsh wrote: post #21

Earlier quoted context omitted.

Though I agree with your sentiment, I must mention that there is nothing "weak" about Python's type system. You likely meant "dynamic", not "weak". See here: wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language

Python's type system is weak whether they self-identify that way or not. Types are implicitly converted in a variety of cases, notably True-ness. Meanwhile, runtime type identity is kind of meaningless; classes and individual objects can have their behavior meaningfully changed at runtime. The most you can say about any variable in Python is that it is a descendant of 'object' or else some primitive type.

Types are implicitly converted in a variety of cases, notably True-ness

First off, see my other comment about Python's boolean type and the fact that it is an integral type:

https://news.ycombinator.com/item?id=9595988

Second, boolean evaluation of arbitrary types in Python is not "weak" -- it's well-defined through a standard language-level protocol, and it's always very clear what can and can't be evaluated as a boolean and what boolean values will result from doing so.

Re: PEP 0484 – Type Hints is accepted

#62

Post by rnnr »

cma wrote: post #58
Veedrac wrote: post #38

Earlier quoted context omitted.

If Python's `if` is weakly typed, then Rust's `for` and `.` are weakly typed. Few would say that, though.

One place where Python is pretty weakly typed is going the other way, where it accepts things like: true + true * 2 - false / true, even outside of if statements. I've definitely been bitten by this before, accidentally passing in a book parameter instead of an int, and having some math work initially and then blow up months later. Knuth argues against this kind of implicit bool to integer conversion in Concrete Math…

It is so because in the beginning python didn't have a boolean type. It used 0 and 1 integers instead. Later when bool was introduced it was a subclass of integers.

Re: PEP 0484 – Type Hints is accepted

#63

Post by deckiedan »

dimino wrote: post #45

This is a tragedy, as it forces comments to contain syntactic value.

Not quite. The PEP is (to me) quite explicit that the typing is never mandatory. So a comment-hint will never change the way the code actually runs, nor will lack of a comment or an unintentional comment cause a program to act strangely.

Already, anyone seriously using pylint or other "normal" python linting tools uses comments like that to give extra hints to the linter:

    def blah(): # pylint: ignoresomething
type of thing. Yes, it's a bit weird, and yes, it does teeter right on the edge of the comments as syntactic value precipice, but I think lands just on the alright side.

Re: PEP 0484 – Type Hints is accepted

#64

Post by jghn »

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…

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

Re: PEP 0484 – Type Hints is accepted

#65

Post by coldnebo »

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…

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?

Re: PEP 0484 – Type Hints is accepted

#66

Post by jghn »

coldnebo wrote: post #65
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…

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?

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.

Re: PEP 0484 – Type Hints is accepted

#67

Post by cma »

ubernostrum wrote: post #60
cma wrote: post #58

Earlier quoted context omitted.

One place where Python is pretty weakly typed is going the other way, where it accepts things like: true + true * 2 - false / true, even outside of if statements. I've definitely been bitten by this before, accidentally passing in a book parameter instead of an int, and having some math work initially and then blow up months later. Knuth argues against this kind of implicit bool to integer conversion in Concrete Math…

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.

Re: PEP 0484 – Type Hints is accepted

#68

Post by cma »

rnnr wrote: post #62
cma wrote: post #58

Earlier quoted context omitted.

One place where Python is pretty weakly typed is going the other way, where it accepts things like: true + true * 2 - false / true, even outside of if statements. I've definitely been bitten by this before, accidentally passing in a book parameter instead of an int, and having some math work initially and then blow up months later. Knuth argues against this kind of implicit bool to integer conversion in Concrete Math…

It is so because in the beginning python didn't have a boolean type. It used 0 and 1 integers instead. Later when bool was introduced it was a subclass of integers.

Wish they dropped it in the move to 3

Re: PEP 0484 – Type Hints is accepted

#69

Post by rurban »

reeboo wrote: post #12
bkeroack wrote: post #10

One of the reasons why I use Python 3.x exclusively is for the new function annotations, which allow use of this: https://github.com/prechelt/typecheck-decorator This allows me to write Python in a design-by-contract style with full, rich runtime type checks. My bug count has gone down dramatically, and when I do find a bug it's virtually always via a typecheck exception.

Yeah, isn't that amazing? I really think this "type" idea is a good one. I wonder if other languages have thought about following Python's lead and adding a type system.

> Following Python's lead and adding a type system

Joking? Python really is almost the last of all dynamic languages to come up with syntax for that. common lisp, scheme, perl, ruby, javascript, php have all syntax for optional typing already, only Guido was against it for years. Which eventually led to Go being developed by Google, and python's downfall. They try to catchup now, but this proposal is only 10% of an optional type system. I miss the inferencer and the optimizations still.

Re: PEP 0484 – Type Hints is accepted

#70

Post by prodigal_erik »

jghn wrote: post #64
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…

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

This. Every test just explores one special case of the invariant I would prefer to enforce but cannot with today's tooling.
Post reply on HN