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

Are you expected to run five Python type-checkers now?

pyrefly.org

Post reply on HN
Print view View original

31–40 of 220 posts

Re: Are you expected to run five Python type-checkers now?

#31

Post by fg137 »

ocamoss wrote: post #16
dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

Running more type checkers isn't really about strictness. The main benefit to library maintainers is to make sure that their APIs are compatible with whatever tools their users run. This wouldn't really be an issue for most other languages, but Python's typing ecosystem is uniquely fragmented, with only partial standardization between several popular tools.

Hmm... that doesn't answer the question?

Re: Are you expected to run five Python type-checkers now?

#32

Post by vitorsr »

kingstnap wrote: post #18

The fact that this article seems to honestly recommend people run 5 different type checkers on library test suits really reflects the tacked on feeling of Python typing.

I am not sure it is recommending more than it is commenting on the current state of developing public-facing APIs in Python.

The downstream users that import the package either have to ignore checking its exported types altogether, manually stub it, or have a subpar development experience to varying degrees.

This is something I saw the other day with some package that provided comprehensive stubs for an untyped library. The .pyi file was littered with comments about quirks from the numerous type checkers (five now).

Re: Are you expected to run five Python type-checkers now?

#33

Post by Someone »

ghostly_s wrote: post #30

Why would users care if you're using the same type checker as them? Surely they're not expecting all their imports to be instrumented for running redundant types checks?

Users do not care about that, but they want to not see type errors or warnings when they integrate your API in their code.

That’s why you want to run their type checker on your API. you cannot know what “their type checker” is, so you want to run all popular type checkers on your API.

Re: Are you expected to run five Python type-checkers now?

#34

Post by srean »

SatvikBeri wrote: post #24
dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.

You could try Cython and Lush. An ML dialect for ML would have been nice, but doesn't exist.

Re: Are you expected to run five Python type-checkers now?

#35

Post by hmry »

voidUpdate wrote: post #9
xemdetia wrote: post #6

Earlier quoted context omitted.

I thought JavaScript language equality quirks was seen as problematic not a missing feature in Python.

At least in javascript, it tells you if things are equal or not. In python, apparently you could answer if A is equal to B with "beans" or 17 or ['a']

Never understood this complaint about operator overloading.

In any language, a function called `isEqual` could wipe your hard drive and replace your wallpaper with a photo of a penguin. Therefore, letting programmers pick the names of their functions is bad? No, obviously naming things for least surprise is the programmer's responsibility.

But when it's the symbols `==` instead of an ASCII name, it's a problem in language design?

(FWIW in Javascript, being unable to override == is actually a problem when you want to use objects as Map keys)

Re: Are you expected to run five Python type-checkers now?

#36

Post by pdpi »

srean wrote: post #34
SatvikBeri wrote: post #24

Earlier quoted context omitted.

What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.

You could try Cython and Lush. An ML dialect for ML would have been nice, but doesn't exist.

As funny as it would be, ML isn't really a great fit for ML, I don't think.

Re: Are you expected to run five Python type-checkers now?

#37

Post by ethagnawl »

dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

Yeah, I can't say I really get the appeal of gradual typing. It's commented/documented code at best and outright lies at worst. Sure, you can build tooling around it and improve your DX a bit but isn't it always a house of cards?

Re: Are you expected to run five Python type-checkers now?

#39

Post by data-ottawa »

throwaway894345 wrote: post #21
xemdetia wrote: post #6

Earlier quoted context omitted.

I thought JavaScript language equality quirks was seen as problematic not a missing feature in Python.

Python never met a footgun it didn’t need to adopt. In this case, however, it’s not equality checks, but operator overloading. I was a Python developer for a decade before switching to Go and life on this side is so much better.

Operator overloading has never been an issue for me, but terminating a line with a comma creating a tuple, or white space (including new lines) between strings to concatenate have cost me days of work over the years.

I understand why those exist, but they’re pure evil.

Re: Are you expected to run five Python type-checkers now?

#40

Post by cogman10 »

pmontra wrote: post #23
dsign wrote: post #15

If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?

Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.

It's not an all or nothing thing.

I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not.

Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and catch bugs that you might otherwise miss.

Post reply on HN