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

The benefits of static typing without static typing in Python

pawelmhm.github.io

Post reply on HN
Print view View original

61–68 of 68 posts

Re: The benefits of static typing without static typing in Python

#61

Post by pka »

nickpsecurity wrote: post #59
pka wrote: post #56

Earlier quoted context omitted.

Well, this is basically what types are :)

No, not imperative types. Tests run specific data through one or more functions for a variety of reasons. Each run will have some successful or flawed effect. Different values of the same type of data can have different results. So, generating test values from specs and types automatically is different from merely typing the data or functions. And, again, I'm talking traditional types like in Java or C++ rather than…

Oh, yeah - something like QuickCheck [0] is great! There are Java and C++ implementations as well, though I haven't tried them. Definitely a nice alternative to traditional unit testing whenever possible. I don't know how well it mixes with unrestricted IO like in Java etc though.

[0] https://en.wikipedia.org/wiki/QuickCheck

Re: The benefits of static typing without static typing in Python

#62

Post by sitkack »

dzbarsky wrote: post #41
mcguire wrote: post #29

What does mypy do if you make a call from code with type annotations into code without? Or vice-versa? Has anyone ever gotten paid to add annotations to code that works? Personally, I view type systems as like a safety line when doing work on a roof, and optional typing as having a line that might or might not be tied off.

> What does mypy do if you make a call from code with type annotations into code without? Or vice-versa? It's not able to analyze across such boundaries, but as you expand the set of typed code you get better and better coverage. > Has anyone ever gotten paid to add annotations to code that works? At Dropbox, we're starting to add type annotations to code. We're confident it will catch many bugs at lint time. Source:…

Are you also using property based testing?

Re: The benefits of static typing without static typing in Python

#63

Post by nickpsecurity »

pka wrote: post #61
nickpsecurity wrote: post #59

Earlier quoted context omitted.

No, not imperative types. Tests run specific data through one or more functions for a variety of reasons. Each run will have some successful or flawed effect. Different values of the same type of data can have different results. So, generating test values from specs and types automatically is different from merely typing the data or functions. And, again, I'm talking traditional types like in Java or C++ rather than…

Oh, yeah - something like QuickCheck [0] is great! There are Java and C++ implementations as well, though I haven't tried them. Definitely a nice alternative to traditional unit testing whenever possible. I don't know how well it mixes with unrestricted IO like in Java etc though. [0] https://en.wikipedia.org/wiki/QuickCheck

Now you're getting the idea. QuickCheck is a good example. I was going to drop an example from safety-critical industry but there's too many now for me to find it lol. Anyway, thanks to our discussion, I did find this great page with links to surveys, list of strategies, and listings of tools:

http://mit.bme.hu/~micskeiz/pages/code_based_test_generation...

Enjoy!

Re: The benefits of static typing without static typing in Python

#64

Post by qwer »

echelon wrote: post #22
qwer wrote: post #20

Since I unit-test the heck out of my code, this doesn't really do much for me. Unit-tests test actual values (which is where the interesting bugs come from IMO) and give me more powerful refactoring capabilities than an IDE. The real benefit I'd be looking for is the chance to give the compiler hints to speed up execution times.

I don't think this is true at all. You cannot write unit tests for all plausible values sent to your functions. If you omit manual type checking in your code or in the respective unit test, you may miss some subtle failure scenarios. Undergoing a refactor, maintenance, or change from other people (or even yourself at a later point in time) only makes this more possible. I personally find that type safety cuts down th…

> You cannot write unit tests for all plausible values sent to your functions.

While this is true, static type checks do even less for this problem. Do you even create specific types for value ranges eg IntegerBetweenZeroAnd100? You're in a vast minority if so, and I'd be interested to see how tedious it is to construct all these non-native types everywhere.

> If you omit manual type checking in your code or in the respective unit test, you may miss some subtle failure scenarios.

There's generally not much that's subtle about a wrong type. If the code is executed at all, it will usually blow up. In my experience, the subtlety comes in the values.

> I personally find that type safety cuts down the number of unit tests I write by half

I just don't buy this (but then again my team goes for near total coverage). Nowhere near 50% of our tests are testing anything that would be solved by static types.

Re: The benefits of static typing without static typing in Python

#65

Post by pka »

nickpsecurity wrote: post #63
pka wrote: post #61

Earlier quoted context omitted.

Oh, yeah - something like QuickCheck [0] is great! There are Java and C++ implementations as well, though I haven't tried them. Definitely a nice alternative to traditional unit testing whenever possible. I don't know how well it mixes with unrestricted IO like in Java etc though. [0] https://en.wikipedia.org/wiki/QuickCheck

Now you're getting the idea. QuickCheck is a good example. I was going to drop an example from safety-critical industry but there's too many now for me to find it lol. Anyway, thanks to our discussion, I did find this great page with links to surveys, list of strategies, and listings of tools: http://mit.bme.hu/~micskeiz/pages/code_based_test_generation... Enjoy!

Looks great, thanks!

Re: The benefits of static typing without static typing in Python

#66

Post by ubernostrum »

incepted wrote: post #14
japhyr wrote: post #7

Earlier quoted context omitted.

I haven't done large-scale refactoring work before. How does typing help with refactoring? Is it because you know exactly what's being passed into a function?

You missed "automated" in "automated refactorings". This is what I'm talking about. Without types, IDE's can't perform automated refactorings: you need to supervise them and make sure the IDE didn't break code. This can't happen with static types.

Without types, IDE's can't perform automated refactorings

This is your obligatory reminder that the entire concept of automated refactoring was first developed in a dynamically-typed language.

Re: The benefits of static typing without static typing in Python

#67

Post by ubernostrum »

Animats wrote: post #55

The Python PEP 0484 approach, unchecked type hints, is strange, and probably a bad idea. There are good arguments for entirely dynamic typing, or entirely static typing, or optional static typing. Those have all been used successfully in other languages. But optional static typing without checking is new. (It may have been tried in some forgotten language, but it never made it into a mainstream one.) This is likely t…

Also, Python is getting header files (called "stub" files), like C. In most modern languages, such as Go and Rust, that's all handled automatically by storing type info in the object files. But in future Python, that will be manual.

Stub files are not mandatory; type annotations can be in the same file as the code. This is perfectly legal, for example:

    def add(first_value: int, second_value: int) -> int:
        return first_value + second_value
Stub files exist because the syntax support didn't exist in earlier versions of Python, so if you write a library that supports older versions of Python you ship a stub file rather than causing syntax errors for a subset of your users.

Re: The benefits of static typing without static typing in Python

#68

Post by ubernostrum »

TazeTSchnitzel wrote: post #26

Having type annotations that are ignored at runtime would cause problems when you interact with code without type annotations, no? PHP has a (unfortunately quite limited) set of type annotations, but the interpreter actually enforces them.

Having type annotations that are ignored at runtime would cause problems when you interact with code without type annotations, no?

I seem to be doing this a lot in this thread, but...

This is your obligatory reminder that several statically-typed languages actually run on dynamic-language runtimes, because programmers don't like to think about the cost of polymorphism/generics, but implementers have to think about that.

Post reply on HN