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

Python’s “type hints” are a bit of a disappointment to me

uninformativ.de

Post reply on HN
Print view View original

391–400 of 597 posts

Re: Python’s “type hints” are a bit of a disappointment to me

#391

Post by arinlen »

bayesian_horse wrote: post #349
arinlen wrote: post #342

Earlier quoted context omitted.

> What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. I'm not sure if that's true. Doesn't Pandas handle ETL and some anaysis? There is nothing inherent to ETL that makes it a hard problem with compiled languages. In your opinion, what does Pandas do that's hard to do with compile-time languages?

I didn't say "with compile-time languages" but "with compile-time type systems". And many similar tools in a statically typed language will necessarily create a way to have one static type that doesn't care what the data inside actually looks like. This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor. Worse,…

> This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor.

That doesn't sound like a Python problem.

Instead, it sounds like the natural consequence of numpy being designed in a way where their data types aren't organized into subtypes, and leave that as runtime properties. This is a natural reflection of numpy's take on vectors, matrices, and tensors, which in terms of types are just big arrays with runtime properties.

To put things in perspective, in C++, Eigen supports static dense vectors and matrices whose size is specified and known at compile-time. I'm sure Python doesn't impose addition static type constraints than C++.

Re: Python’s “type hints” are a bit of a disappointment to me

#392

Post by smallerfish »

qsort wrote: post #378
krageon wrote: post #367

Earlier quoted context omitted.

> Pandas does is notoriously hard to fit into a compile-time type system What, mutate data with known structure? What exactly do you imagine is hard about this, let alone notoriously so?

Not hard per se, but extremely unergonomic. A pandas dataframe types to something like Iterable[SomeKindOfProductType[int, str, str, ... (78 other columns)]]. The formal type of a dataframe in the middle of a transformation is... not very useful to know.

You wouldn't typically type tabular data in any language. Give it (at most) a DataFrame type if you must, where StoreTransaction describes the structure of a row - maybe declaring only columns that model generation code was doing typed operations on (e.g. numerics vs strings) to avoid the need for reflection.

Re: Python’s “type hints” are a bit of a disappointment to me

#393

Post by ReflectedImage »

retrac wrote: post #33
jonathan-adly wrote: post #7

100% agree - never really understood the movement behind adding types to Python. Type hints are a useless complexity that yield little return. If you want types, use something else other than Python. The whole thesis behind Python is simple is better than complex.

> useless complexity that yield little return Typechecking allows certain errors to be detected at typecheck time rather than at runtime. I don't personally consider that useless. E.g. A mistake I just made. I'm working in a language I don't know too well right now with strict static typing. The file read function takes a handle. If I pass it a string of the file name, rather than the handle result from file open, it…

The changes you need to make to a Python program to enable it to be type checked result in more bugs being added than the type checker removes leaving you at a net negative.

Type checking is just a really poor way to ensure program correctness until you start using an exceptionally strongly typed language like Haskell.

You use types in C / C++ / Java because the compiler needs them to work not because it's a good idea.

Re: Python’s “type hints” are a bit of a disappointment to me

#394

Post by necovek »

Too wrote: post #296
neves wrote: post #269

Earlier quoted context omitted.

Nice. How do you force types just in the new code?

Mypy can be configured to ignore modules based on their names. Though honestly I think it’s worth it to just bite the bullet and spend a full day or two to go through and fix every single error. After this you will have a much easier time navigating code base. I mean, your “new code” is probably modifications to your old code or calling your old code right? So you want to have at least the boundary between new and ol…

With any large legacy Python codebase, that's usually a month-long undertaking for one engineer, if not longer!

Python by design encourages duck typing, which means that you'll have plenty of places that simply take multiple different types, and just slapping a union is usually non-trival and not very beneficial either (eg. you'd be randomly patching things with fakes and mocks in tests).

If you think it's a single day job, I am sure my company (and plenty others) would pay you gladly your single daily rate to get our codebase migrated in a day :-D

Re: Python’s “type hints” are a bit of a disappointment to me

#395

Post by pydry »

bayesian_horse wrote: post #301
pydry wrote: post #61

Earlier quoted context omitted.

I've been perplexed as to why this hasnt been built in to the python runtime since day 1.

Python was first released in 1991.

And day 1 of when type hints was introduced was in 2014.

Re: Python’s “type hints” are a bit of a disappointment to me

#396

Post by fulafel »

Humphrey wrote: post #118

While I love the idea behind Python's type hints, they are merely a shadow of the success of TypeScript. Like the author, I've mostly given up on adding type hints in my Python code. I now only use them when I want to help my IDE find autocomplete suggestions. Whereas TypeScript was a game changer for JavaScript. I used to hate JavaScript, but somehow TypeScript has become one of my favourite languages! How has the a…

The realities of the browser platform have indeed created a unique environment where many nice languages have appeared that compile to JS. Besides TypeScript there's Elm, ReasonML, ClojureScript, and many more.

There are a some competing languages for the Python runtime as well: https://github.com/vindarel/languages-that-compile-to-python

Re: Python’s “type hints” are a bit of a disappointment to me

#397

Post by toolslive »

bayesian_horse wrote: post #301
pydry wrote: post #61

Earlier quoted context omitted.

I've been perplexed as to why this hasnt been built in to the python runtime since day 1.

Python was first released in 1991.

Type inference has been around (as in "used in programming languages") since the early 1970s. In the beginning python hit a sweet spot: glue code that wasn't exactly write once, too difficult to do in bash, and too small to go all the way and use C++. However, it was not without its own design issues.

Re: Python’s “type hints” are a bit of a disappointment to me

#398

Post by nyuszika7h »

neves wrote: post #269
jsmeaton wrote: post #239

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…

Nice. How do you force types just in the new code?

You can use flakehell for that.

Re: Python’s “type hints” are a bit of a disappointment to me

#399

Post by da39a3ee »

I agree with everything in this article. The fact that nothing is necessarily checking them makes a codebase full of them too misleading. They become cargo culting; and as the article says their special syntactic status makes them look “official”. Typescript is much better since you can’t avoid them being checked. And that’s said as someone who spent the last decade writing Python, in later years with type hints. There’s also a mypy option that is not on by default but that is absolutely required to avoid misleading false negatives: —-check-untyped-defs

Re: Python’s “type hints” are a bit of a disappointment to me

#400

Post by toolslive »

ImprobableTruth wrote: post #253
zmgsabst wrote: post #201

Earlier quoted context omitted.

Your suggestion to “use a recursive union type” and that being “ugly … if your type checker doesn’t … support recursive types” being required to support varying JSON is my point: Python types don’t support a common Pythonism used frequently in my work. In fact, you admit that even fixed JSON can be difficult without a 3rd party library. You’re lecturing me like I don’t understand types without realizing that you repe…

I think I might not have been clear: this is not a limitation of the type system , but of a specific type checker (mypy), that will hopefully be fixed soon. Both Pyright and Pyre support recursive type aliases right now . Open one of their playgrounds and you'll see that the following, intuitive definition JSON = Union[ None, bool, int, float, str, List['JSON'], Dict[str, 'JSON'], ] works without issue. >In fact, you…

> JSON = Union[....]

This does not define the type of a valid json object. (fe None is not a valid json object, neither is '')

Post reply on HN