Live data from Hacker News

PyAnnotate – Auto-generate type annotations for mypy

mypy-lang.blogspot.com

21–30 of 34 posts

Re: PyAnnotate – Auto-generate type annotations for mypy

#21
post #16

Earlier quoted context omitted.

Citation needed? Anecdotally, I've developed large projects in C++ and Java (I know, they're pretty lame static type systems -- but certainly the most popular static type systems) and also in Python and Clojure and I really haven't seen much benefit in static typing in regards to software defect rate or quality. Static typing make auto complete and refactoring tools easier, for sure, but it also slows down ease of ex…

> I really haven't seen much benefit in static typing in regards to software defect rate or quality Hold it right there. I've never seen anyone argue that static type systems prevent bugs. I mean they do prevent silly bugs that occur from mistyping variable/property names but I've never seen anyone claim that they eliminate other classes of bugs. The biggest benefit of static type checking is you know what all the va…

> I've never seen anyone argue that static type systems prevent bugs.

It's extremely common to claim that static typing prevents entire classes of bugs (and I agree!). Here's just one instance of such a claim I found on Google:

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

Re: PyAnnotate – Auto-generate type annotations for mypy

#22
post #20

Earlier quoted context omitted.

Citation needed? Anecdotally, I've developed large projects in C++ and Java (I know, they're pretty lame static type systems -- but certainly the most popular static type systems) and also in Python and Clojure and I really haven't seen much benefit in static typing in regards to software defect rate or quality. Static typing make auto complete and refactoring tools easier, for sure, but it also slows down ease of ex…

> I just don't think we have found a static type system yet that has the right balance of convenience and safety and actually catches the right kinds of errors (as described in the below talk). "Please don't be an uninformed Rich Hickey talk" "Oh, it's an uninformed Rich Hickey talk"

Explain?

Re: PyAnnotate – Auto-generate type annotations for mypy

#23
post #19

Earlier quoted context omitted.

>Hold it right there. I've never seen anyone argue that static type systems prevent bugs. Really? I see this every single time the subject is brought up. And, to be fair, they do catch some bugs, it's just that they do so at a cost. >What the hell is customer? What is payment methods? What fields are available on these objects? What methods can you call on them? no freaking idea. And, if they are all strings, how muc…

What is behavioral test? Like, I don't understand all these weird paradigms that people come up with to deal with the deficiencies of dynamic typing. If declaring structs is seen as costly overhead that complicates coding, tests are when more cumbersome.

>What is behavioral test?

A behavioral test is a test that tests the behavior of a piece of software, as opposed to a test that checks types or implementation details or something else that isn't behavior.

It is perhaps not necessary to write tests like these in languages that produce code that does not have bugs. I have yet to encounter such a language.

>If declaring structs is seen as costly overhead that complicates coding, tests are when more cumbersome.

You do not write tests then?

Re: PyAnnotate – Auto-generate type annotations for mypy

#24
post #16

Earlier quoted context omitted.

Citation needed? Anecdotally, I've developed large projects in C++ and Java (I know, they're pretty lame static type systems -- but certainly the most popular static type systems) and also in Python and Clojure and I really haven't seen much benefit in static typing in regards to software defect rate or quality. Static typing make auto complete and refactoring tools easier, for sure, but it also slows down ease of ex…

> I really haven't seen much benefit in static typing in regards to software defect rate or quality Hold it right there. I've never seen anyone argue that static type systems prevent bugs. I mean they do prevent silly bugs that occur from mistyping variable/property names but I've never seen anyone claim that they eliminate other classes of bugs. The biggest benefit of static type checking is you know what all the va…

Except that static typing doesn’t help much there either (unless perhaps you’re using Frink with its units). The type doesn’t carry enough information. For example, knowing that something is an integer really doesn’t give you enough context about what that integer means or is used for. If it’s an object or strict, ok, then it helps to document, but if it’s primitive or standard collections...

Anyway, in Clojure, we now use spec to specify the shape of data that we expect, with nice descriptive namespaced keyword names. It helps in validating data entering the system, generating test data and as documentation.

Re: PyAnnotate – Auto-generate type annotations for mypy

#25
post #18

Earlier quoted context omitted.

>Hold it right there. I've never seen anyone argue that static type systems prevent bugs. Really? I see this every single time the subject is brought up. And, to be fair, they do catch some bugs, it's just that they do so at a cost. >What the hell is customer? What is payment methods? What fields are available on these objects? What methods can you call on them? no freaking idea. And, if they are all strings, how muc…

> IMHO behavioral tests perform this function equally well. I think a common pitfall in these discussions is to compare the worst case examples rather than reasonable quality codebases. I'd be far more interested in, say, time/cost to correct result metrics for a well-maintained Python codebase which has reasonable use of tests & linting (e.g. flake8) to an equivalently-proficient team using a statically typed langua…

If we're discussing well-maintained code, then I would expect that the public interface is documented, at least in docstrings. Then I also know what the parameters are.

Re: PyAnnotate – Auto-generate type annotations for mypy

#26
post #18

Earlier quoted context omitted.

> IMHO behavioral tests perform this function equally well. I think a common pitfall in these discussions is to compare the worst case examples rather than reasonable quality codebases. I'd be far more interested in, say, time/cost to correct result metrics for a well-maintained Python codebase which has reasonable use of tests & linting (e.g. flake8) to an equivalently-proficient team using a statically typed langua…

If we're discussing well-maintained code, then I would expect that the public interface is documented, at least in docstrings. Then I also know what the parameters are.

Agreed — I'm just wondering about how to quantify the impact of various changes. A dynamic language project with no tests, etc. is going to look like a selling point for static typing but I suspect the real-world bug counts for, say, a Python project using mypy (or even flake8 + tests + coverage) is going to be a lot closer than you might think from how heated these discussions get.

Re: PyAnnotate – Auto-generate type annotations for mypy

#27
post #19

Earlier quoted context omitted.

What is behavioral test? Like, I don't understand all these weird paradigms that people come up with to deal with the deficiencies of dynamic typing. If declaring structs is seen as costly overhead that complicates coding, tests are when more cumbersome.

>What is behavioral test? A behavioral test is a test that tests the behavior of a piece of software, as opposed to a test that checks types or implementation details or something else that isn't behavior. It is perhaps not necessary to write tests like these in languages that produce code that does not have bugs. I have yet to encounter such a language. >If declaring structs is seen as costly overhead that complicat…

No I do not. I specially don't write unit tests.

Re: PyAnnotate – Auto-generate type annotations for mypy

#28
post #26

Earlier quoted context omitted.

If we're discussing well-maintained code, then I would expect that the public interface is documented, at least in docstrings. Then I also know what the parameters are.

Agreed — I'm just wondering about how to quantify the impact of various changes. A dynamic language project with no tests, etc. is going to look like a selling point for static typing but I suspect the real-world bug counts for, say, a Python project using mypy (or even flake8 + tests + coverage) is going to be a lot closer than you might think from how heated these discussions get.

There was a study that did a line by line translation of 4 python projects to haskell and caught some bugs (between 0 and 4 per project): http://evanfarrer.blogspot.co.uk/2012/06/unit-testing-isnt-e...

I got the impression that the bugs found were either not at all serious (e.g. throwing a typeerror on malformed input instead of some other nicer kind of error) or were in areas of the code not covered by tests.

Unfortunately the author does not rate them by severity.

Re: PyAnnotate – Auto-generate type annotations for mypy

#29
post #12
post #9

Earlier quoted context omitted.

I somewhat agree but I think they will be optionally typed (and for that matter, optionally borrow checked), more along the lines of Julia. Where type stable code gets the performance benefits of static typing, even if it doesn't use any static typing. And where types can be added at any point to improve type checking, performance, and polymorphism all at once. This allows for fast prototyping, and when done correctl…

I disagree, static typing shouldn't be optional.

Why?

Re: PyAnnotate – Auto-generate type annotations for mypy

#30
post #12
post #9

Earlier quoted context omitted.

I somewhat agree but I think they will be optionally typed (and for that matter, optionally borrow checked), more along the lines of Julia. Where type stable code gets the performance benefits of static typing, even if it doesn't use any static typing. And where types can be added at any point to improve type checking, performance, and polymorphism all at once. This allows for fast prototyping, and when done correctl…

I disagree, static typing shouldn't be optional.

Do you actually mean explicit typing as opposed to merely static typing? How about type inference?
Post reply on HN