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

Python type hints may not be not for me in practice

utcc.utoronto.ca

Post reply on HN
Print view View original

101–110 of 209 posts

Re: Python type hints may not be not for me in practice

#101

Post by tacticus »

hbrn wrote: post #67
belorn wrote: post #37

Earlier quoted context omitted.

Looking at that blog post, I find it illustrative in how people who like strong types and people who dislike strong types are addressing different form of bugs. If the main types of issues comes from bugs like 1 + "2" == 12" , then strong types is a big help. It also enables many developers who spend the majority of time in a programming editor to quickly get automatic help with such bugs. The other side is those peo…

What's even worse, when typing is treated as an indisputable virtue (and not a tradeoff), pretty much every team starts sacrificing readability for the sake of typing. And lo and behold, they end up with _more_ design bugs. And the sad part is that they will never even recognize that too much typing is to blame.

> pretty much every team starts sacrificing readability

People are sacrificing this when they start using python in the first place

Re: Python type hints may not be not for me in practice

#102

Post by daelon »

patrickkidger wrote: post #64
CJefferson wrote: post #54

Earlier quoted context omitted.

Mainly, the seems to be no way, in a dynamic language, to dynamically check if functions get the right types. To me, this means I don't really understand the python type hinting at all, as adding hints to just one or two functions provides no value to me at all. I assume I must be not using them usefully, as I've tried adding type hints to some projects and they just seemed to do nothing useful.

You want runtime typechecking. See either beartype [1] or typeguard [2]. And if you're doing any kind of array-based programming (JAX or not), then jaxtyping [3]. [1] https://github.com/beartype/beartype/ [2] https://github.com/agronholm/typeguard [3] https://github.com/patrick-kidger/jaxtyping

Thanks for posting this. I had seen beartype several years ago but I don't believe it had the whole-module registration feature yet. I'm looking forward to trying both of the libraries since the ergonomics are better than decorating every function individually.

Re: Python type hints may not be not for me in practice

#103

Post by chamomeal »

maleldil wrote: post #92

Something I didn't see mentioned much here is refactoring. Refactoring without types is like walking in the dark. You have to check everywhere to see how your changes impact other code, and you'll certainly miss some and only find out in production. With typing, when you change your type signature, you can just run the checker and get a list of places you need to change.

Yeah to me this is the biggest difference between static/dynamic types. I mean there are a LOT of differences DX-wise, but refactoring is so scary without static types.

If we need to make changes to the DB at work, I’ll just update the prisma schema and run ‘npx prisma generate’ followed by ‘tsc —noEmit’ to instantly see all the affected areas. I feel like there are a lot of similar little superpowers you get by having a nice static type system.

Re: Python type hints may not be not for me in practice

#104

Post by chamomeal »

truculent wrote: post #23

The problem (in my opinion) is that Python gives you the tools (and perhaps even encourages you) to write code that would benefit from typing. It's perfectly feasible to write maintainable, well-designed code in a dynamic language. I've worked with some extremely robust and ergonomic Clojure codebases before, for example. However, in Clojure, the language pushes you into its own "pit of success". Personally, I never…

That’s good to hear about clojure!

I just started learning the language and it’s been a ton of fun (especially babashka omg) but I’m so typescript-minded that it’s been really tough being back in dynamic land.

Re: Python type hints may not be not for me in practice

#105

Post by nayuki »

wenc wrote: post #39
greatgib wrote: post #8

The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. I'm missing a lot simple functions with explicit argument names and docstrings with arguments types and descriptions clearly but discreetly documented. It was one big strength of Python to have so simple and clean code without too much boilerplate. Also, I have the feeling that static typing extremis…

> The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. Compared to legacy Python, yes. Compared to verbose language like Java, no. Python typing is equal or less verbose than Java (unless you use "var" in Java).

Technically, Python typing is more verbose than Java because it uses more tokens. Compare these:

    Python: def foo(x: int, y: int) -> int:  return x + y

    Java: int foo(int x, int y) { return x + y; }
Python uses colons and arrows while Java uses positions to encode where the type should go.

Re: Python type hints may not be not for me in practice

#106

Post by emeryberger »

I agree that writing type hints can be painful, especially if you are starting with a large code base that is mostly untyped. You might consider using RightTyper (https://github.com/RightTyper/RightTyper) - basically run your Python 3.12+ program with it, and it will add type hints to your code. It’s fast, basically automatic, and by design RightTyper avoids overfitting to your types, letting a type checker like MyPy surface edge cases. In effect, the type checker becomes an anomaly detector (Full disclosure, I am one of the authors of RightTyper.)

From the GitHub page:

RightTyper is a Python tool that generates types for your function arguments and return values. RightTyper lets your code run at nearly full speed with almost no memory overhead. As a result, you won't experience slow downs in your code or large memory consumption while using it, allowing you to integrate it with your standard tests and development process. By virtue of its design, and in a significant departure from previous approaches, RightTyper only captures the most commonly used types, letting a type checker like mypy detect possibly incorrect type mismatches in your code.

Re: Python type hints may not be not for me in practice

#107

Post by joshdavham »

emeryberger wrote: post #106

I agree that writing type hints can be painful, especially if you are starting with a large code base that is mostly untyped. You might consider using RightTyper ( https://github.com/RightTyper/RightTyper ) - basically run your Python 3.12+ program with it, and it will add type hints to your code. It’s fast, basically automatic, and by design RightTyper avoids overfitting to your types, letting a type checker like My…

Why is your GitHub organization’s logo, the AWS logo?

Re: Python type hints may not be not for me in practice

#108

Post by emeryberger »

joshdavham wrote: post #107
emeryberger wrote: post #106

I agree that writing type hints can be painful, especially if you are starting with a large code base that is mostly untyped. You might consider using RightTyper ( https://github.com/RightTyper/RightTyper ) - basically run your Python 3.12+ program with it, and it will add type hints to your code. It’s fast, basically automatic, and by design RightTyper avoids overfitting to your types, letting a type checker like My…

Why is your GitHub organization’s logo, the AWS logo?

In addition to being a faculty member at UMass Amherst, I am an Amazon Scholar, working at Amazon Web Services, where this work was conducted.

Re: Python type hints may not be not for me in practice

#109

Post by hbrn »

junyjujfjf wrote: post #89
hbrn wrote: post #79

Earlier quoted context omitted.

How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go? https://charliereese.ca/y-combinator-top-50-software-startup...

They are likely leveraging Django/Rails which treads the beaten path for Startups. Startups are also more likely to do monoliths. For Enterprise & microservices, you will start to see more Java/Go/C#.

I would expect dynamic type crowd to embrace microservices first, given how everybody says that dynamic codebases are a huge mess.

Regardless, to me enterprise represents legacy, bureaucracy, incidental complexity, heavy typing, stagnation.

I understand that some people would like to think that heavy type-reliance is a way for enterprise to address some of it's inherent problems.

But I personally believe that it's just another symptom of enterprise mindset. Long-ass upfront design documents and "designing the layout of the program in types first" are clearly of the same nature.

It's no surprise that Typescript was born at Microsoft.

You want your company to stagnate sooner? Hyperfixate on types. Now your startup can feel the "joys" of enterprise even at the seed stage.

Re: Python type hints may not be not for me in practice

#110

Post by ycombinatrix »

emeryberger wrote: post #108
joshdavham wrote: post #107

Earlier quoted context omitted.

Why is your GitHub organization’s logo, the AWS logo?

In addition to being a faculty member at UMass Amherst, I am an Amazon Scholar, working at Amazon Web Services, where this work was conducted.

how come it isn't hosted under the official aws organization? https://github.com/aws
Post reply on HN