Live data from Hacker News

Python type hints may not be not for me in practice

utcc.utoronto.ca

91–100 of 209 posts

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

#91

The thing that the author says they would prefer is already in Python, it's called NewType ( https://docs.python.org/3/library/typing.html#typing.NewType ) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation w…

This is great, thank you for this. I've always wanted something that would complain if I passed Meters to something expecting Feet, but aliases didn't consider this an error.

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

#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.

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

#93

It seems like the author is looking for the ability to specify types as `typeof :arguments` and `typeof :return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.

Like `ParamSpec`?

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

#94
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#.

This distinction makes no sense. Can you explain why types would be more relevant?

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

#95
post #63

Earlier quoted context omitted.

> Writing software without types lets you go at full speed. Full speed towards the cliff. Isn't it strange that back when Python (or Ruby) didn't even have type hints (not type checkers, type hints!), it would easily outperform pretty much every heavily typed language? Somehow when types weren't an option we weren't going towards the cliff, but now that they are, not using them means jumping off a cliff? Something do…

It's because the nature of typing has changed drastically over the last decade or so, in well known languages, going from C++/Java's `FancyObject *fancyObject = new FancyObject()` (which was definitely annoying to type, and was seen as a way to "tell the compiler how to arrange memory" as opposed to "how do we ensure constraints hold?") to modern TypeScript, where large well-typed programs can be written with barely…

No it hasn’t? C++ type system has hardly changed (until concepts) and is one of the most powerful available.

A certain generation of devs thought types were academic nonsense and then relearned the existence of those features in other languages. Now they are zealots about using them.

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

#97
post #91

The thing that the author says they would prefer is already in Python, it's called NewType ( https://docs.python.org/3/library/typing.html#typing.NewType ) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation w…

This is great, thank you for this. I've always wanted something that would complain if I passed Meters to something expecting Feet, but aliases didn't consider this an error.

You should look into the pint library if you want full unit support!

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

#98
I think TypeScript provides a lot more of the freedom the author is looking for. For instance, you can say, "the type of this argument is whatever is returned by that function."

Personally I find myself more comfortable and productive using types. Stating your types has a similar benefit to journaling, in my view. It's a forcing function for clarifying your ideas about the problem domain. Some perceive this as overhead, I perceive this as front loading. If my ideas are murky, I will run into trouble sooner or later. The later it is, the more painful it will be.

I think it largely comes down to different habits of working and thinking. I don't think one way is superior to another inherently (though types are important for collaboration), but that different people work in different ways.

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

#99
post #91

Earlier quoted context omitted.

This is great, thank you for this. I've always wanted something that would complain if I passed Meters to something expecting Feet, but aliases didn't consider this an error.

You should look into the pint library if you want full unit support!

That looks really useful, thank you! I don't always specifically want units, but it'll be great for when I do!

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

#100
post #21

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

Isn't the rust type system fairly off-topic here? Python is a dynamic language, Rust is on the other end of the scale.

The Rust Evangelism Strike Force used to be more subtle! (joke)

Post reply on HN