Hacker News Reader

Comment by orf | Hacker News Reader

> in practice annotations make code LESS readible, not more

Definitely not true, unless you are writing c++ in Python

> so in practice your team will be skipping annotations - e.g using Dict[str, Any], which defeats the whole purpose of annotations

Using “Dict[str, Any]” doesn’t defeat the whole point of using annotations at all, and adds useful documentation for callers and IDEs. It can also be gradually improved later.

> Typings are still in 0.x version and are constantly changing

Typing is part of the standard library. Some new things are added, but the interface is very stable. Mypy is constantly changing.

> These are solved with proper structure, conventions, testing and developer prep (readme + pairing).

And with some degree of type checking/type annotations.

> If you believe bigger projects need annotations tell me why Sentry didn't go with them yet?

What an odd point to make.

View on HN

> and adds useful documentation for callers and IDEs.

THIS. This is why I started using them, along with standardizing my docstrings. Enormously helpful when you're trying to remember what the function is expecting to just hover it and find out.

Yes, they are probably most useful to me for the IDE completions and docs as well. Raymond Hettinger gave at least one talk [1] where he discussed how there are tradeoffs: reasons why you might use them and reasons why you might not. At the end of the day you can pass whatever you want to a function and the only reason to use types if they make your code better—but there are other tools that might be more worth your time in some situations.

[1]: https://www.youtube.com/watch?v=ARKbfWk4Xyw

I see your points and I was going through pretty much all of them when deciding whether to go with typings or not (eventyally we did because I wanted to try it out and because pressure from Java people who found it odd that we don't care about types - actually we do, but instead of types we have strict naming conventions).

The point with sentry was that when making a decision in field you don't have much experience in, you look what other guys with resources are doing since they had these conversations already.

IMO in practice you will realize that in most cases typings are more of a burden than help - devs don't know typings and will spend a lot of time thinking how to annotate, making constant decisions whether to annotate/not annotate (aka incremental typing). That inconsistency drives me nuts - aka defeats the whole purpose - you do something right or don't do it at all right?

I see the point with documentation, yes it is nice to have, but more important like I said before is proper onboarding readme file and docs + willingness of other devs who are working on the codebase to handhold when necessary.

> you do something right or don’t do it at all

Down that path lies madness. The Boy Scouts rule is to leave the camping ground cleaner than you found it. It doesn’t say the campground has to be spotless.

Great analogy.

I see how this sort of attitude can be seen as mad/neurotic. However the good side is that it prevents adding more complexity (rules for when to annotate/not annotate is adding complexity).

>> Using “Dict[str, Any]” doesn’t defeat the whole point

I think you’ve misunderstood the parent.

That makes two of us. What was the parent trying to say, then?

Python allows gradual typing everywhere. Adding “Dict[str, Any]” gives you value and let’s you catch bugs. Not as much as a more specific signature, but far more than having no annotations.

> Adding “Dict[str, Any]” gives you value and let’s you catch bugs

What types of bugs are you speaking of? Can you share an example?

Remember about constructive feedback method - what, why and how.

You’re asking how type annotations can help you catch bugs. I’m not particularly inclined to synthesise a bunch of examples (especially after the highly condescending initial wording of your comment), it seems fairly obvious and I’m sure you’re smart enough to figure it out.

Can you show me this "initial highly condescending wording of your comment"?

I think we’ll leave this thread here, but if in the future you need to ask something from someone in good faith I would work on refining your wording a bit.

> I’m sure you’re smart enough to figure it out

You are making it personal (well, actually trying to insult), where I was asking you to provide more value.

The classic bugs are passing the wrong type of argument and calling a method on None.

PyCharm did static analysis and caught a lot of these, but it wasn't always that obvious. With a type hint, it's easy for the IDE to spot things. It's easy to integrate mypy into the CI process, etc.

We inherited a py2.7 codebase, written by one dev. It uses a library written also by that dev. We had absolutely no idea what worked how. Sure, looking at the code gave us a very rough big picture, but adding typing helps with the details.

> We inherited a py2.7 codebase, written by one dev. It uses a library written also by that dev. We had absolutely no idea what worked how. Sure, looking at the code gave us a very rough big picture, but adding typing helps with the details.

I see how this could be helpful for legacy codebase - add typings, run mypy and see if it breaks. Good point - thanks.

How many lines of code that inherited codebase had btw?

Quite small in LOCs less than 10K. (A horribly non-idiomatic custom ETL lib, and a big ball of MVC stuff using pyramid and sqlalchemy/zope.transaction.)

e.g. say you're writing some code that does something like this:

account = queryDatabase(email)

updatedUser = update(account)

ping(account)

queryDatabase returns a dictionary. Later on, someone decides that a single username can have multiple accounts, so someone changes queryDatabase to return a list of dictionaries instead of a single dictionary. Now the above code is broken, since update expects a single dictionary. Of course, you could grep through the whole codebase to try and find all the problems, but it would be easier and less prone to human error to rely on the type system to fail, especially if the change was something less contrived, and if changes like this were happening all the time.

The effect of this could be limited by other means (e.g. naming the function better) but type systems are just another way of adding robustness to a program.

Reply on news.ycombinator.com