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

51–60 of 220 posts

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

#51

Post by agons »

voidUpdate wrote: post #7
datsci_est_2015 wrote: post #5

Earlier quoted context omitted.

One example is if an and b are arrays (e.g. numpy arrays) it’s not unreasonable for dunder eq to return an array of booleans. Another example might be if you have a domain specific representation of equality (e.g. class Equality)

I can see the first one making sense, but why would you need a representation of equality other than "yes, these are equal" and "no, these are not equal"?

The first use case that comes to mind is if you want a DSL to build expressions that are evaluated later in some different context e.g. when using `polars`:

```python df.filter( pl.col("foo") == pl.col("bar"), ) ```

Sqlalchemy does something equivalent too, and I'm sure there are many others.

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

#52

Post by IshKebab »

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?

Yes. If you have a choice.

For people who don't have a choice, type checked Python is better than nothing.

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

#53

Post by locknitpicker »

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.

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

Pay no attention to OP. It's nonsensical to even suggest you should migrate away from a whole tech stack just because you want to run static code analysis, specially when the argument is based on having too many static analysis tools to chose from. Utter nonsense.

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

#54

Post by zerof1l »

From my experience with Python, both personal and professional, I find it immature and not well-suited for large codebases. Typing should have become part of the language a long time ago; it is clear that users want it.

Take, for example, PHP… look at the features released in the last 6 or so years, starting with PHP 7, and how mature the language has become.

With the advance of AI-assisted programming, I feel like Python is always a bad choice.

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

#55

Post by vadansky »

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?

Personally because I'm making a blender add on that only uses python, and it's at the complexity where having types catches a ton of bugs easily.

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

#56

Post by hedora »

datsci_est_2015 wrote: post #8
woeirua wrote: post #2

With agents it no longer makes sense to tie yourself to Python's archaic development experience. How many type checkers are there? Package managers? Don't even get me started on cross-platform deployment. Strongly typed, compiled languages have never been easier to use, and agents reap huge benefits from the tight feedback loop that the compiler provides. Moreover the benefits of the Python ecosystem are less signifi…

> Just point some agents at it and you can port it. Don’t think we’re there yet, otherwise we would see a bunch of forks of major libraries to alternative languages - and not just Python. There’s still too much risk of insidious errors and bugs.

I've done thus a few times for stuff in the There's something particularly satisfying about shipping a 1-10MB static rust binary instead of a 2GiB docker python environment.

(I'm talking about just porting simple applications, or maybe a missing package/crate at a time. Not both at once, and not typical 100K-10M line internal legacy sprawl)

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

#57

Post by Hizonner »

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?

Yes, but unfortunately Python has invaded everything, and one must adapt.

Python is going to be preinstalled on almost any machine I use, with a reasonable assortment of libraries. And even if they're not preinstalled, the libraries I want are likely to exist. They'll have unstable APIs and weird quirks, and I'll have to take my choice of bad packaging systems to install them, and everything will just generally be a pain, but they'll exist and largely work. That's not true for any language I actually want to code in. I mean, I'm not going to deny that Python is better than shell scripts or (usually) C.

It's not like it's a pleasant language to code in, especially if you actually want to use the type support, which is weird and irregular and keeps changing and has to work around fundamental design problems at the core of the language.

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

#58

Post by hedora »

vips7L wrote: post #27
cryptonym wrote: post #12

Earlier quoted context omitted.

They also "reap huge benefits from the tight feedback loop that the compiler provides". When something is easier/requires less context, it tends to work well for both human and LLM.

I've noticed this a lot in LLM generated Java. Since it doesn't know what can or can't be null it tends to wrap everything in Optional . Super strong type systems are becoming even more important.

You probably need to tell it to rip as many of those out as possible (and replace them with null annotations).

I've noticed LLMs sometimes pick a documented anti-pattern (passing Optional around in Java is not recommended), then amplify it (like a human might).

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

#59

Post by kibwen »

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.

> To the static typing folks: leave my dynamically typed languages alone

Surely you understand that the push to add types to dynamically-typed languages comes from dynamic-typing folks, not from static-typing folks. People who are deeply into static typing have little incentive to consider e.g. Python, whose support for types is relatively weak, loosely-defined, and rarely-enforced compared to the statically-typed languages that exist today.

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

#60

Post by Hizonner »

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.

The only reason I gave up resisting and started writing any significant code in Python at all was that it got some kind of type system, and thus became less unpleasant to code with.

"Pleasant to code with" does not describe getting "AttributeError: 'NoneType' object has no attribute 'foo'" 25 levels deep in a stack trace already obfuscated by dynamic object-oriented nonsense. In production, because it's an unusual case and testing missed it. Not that test cases aren't way more work than types anyway.

Post reply on HN