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

211–220 of 220 posts

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

#211

Post by nijave »

bborud wrote: post #183
nijave wrote: post #126

Earlier quoted context omitted.

Anything performance sensitive ends up being an extension in compiled code anyway Python is mostly just glue

The performance is not the (only) issue. The issue is the death by a thousand cuts involved in distributing Python programs without a two page set of instructions that have to be followed to make it work. It is rarely "just works" unless you can make a lot of assumptions about the environment it runs in. It's why I generally steer away from any application written in Python. It is going to be painful. However my expe…

> Python fosters a "it works for me" mentality where people don't know and don't care what it is like to be on the receiving end.

In my experience, that's not limited to Python.

> And people generally don't bother to know.

Yes, that's the real problem and transcends ecosystem and toolchain

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

#212

Post by UltraSane »

pjmlp wrote: post #209
UltraSane wrote: post #76

Earlier quoted context omitted.

That is why I'm using C# and Rust more now than Python. You get far better RoI on types. and they are so much faster and can use all cores so much more easily.

You can even add F# into the loop, with REPL and type inference much better than those two.

F# is a really nice language, I just wish I could get paid for writing it.

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

#213

Post by bborud »

nijave wrote: post #211
bborud wrote: post #183

Earlier quoted context omitted.

The performance is not the (only) issue. The issue is the death by a thousand cuts involved in distributing Python programs without a two page set of instructions that have to be followed to make it work. It is rarely "just works" unless you can make a lot of assumptions about the environment it runs in. It's why I generally steer away from any application written in Python. It is going to be painful. However my expe…

> Python fosters a "it works for me" mentality where people don't know and don't care what it is like to be on the receiving end. In my experience, that's not limited to Python. > And people generally don't bother to know. Yes, that's the real problem and transcends ecosystem and toolchain

No, you are right about it not being limited to Python. But for python the common courtesies I am used to right out of the box tend to require extra effort on part of the programmer. And «extra» doesn’t usually happen.

Even C, with its ancient, haphazard, ugly, fragile, awkward toolchain, can often trivially produce binaries that will just work with very little effort.

I have spent decades of my life writing tooling, libraries and infrastructure. And no matter where you go, developers only do the bare minimum if they can get away with it. That doesn’t mean they are bad people. It means tools and infrastructure has to be designed with acute awareness of reality.

Python has been around for 35 years. And it still hasn’t evolved things we should take for granted today despite its increase in adoption. To me that’s pretty fucking awful project governance.

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

#214

Post by throwaway81523 »

strogonoff wrote: post #182
zelphirkalt wrote: post #148

Earlier quoted context omitted.

So far I have been avoiding Pydantic as a huge-ass dependency. Instead I am relying on standard type annotations, lots of typed dicts and at service/program boundaries use a jsonschema. I like being able to specify the type of most functions, and get some hints, completions and so on, but I don't want to _have to_ specify every darn type. I also don't want to write a class for everything. Typing dicts is good and usu…

I tend to get triggered when TypeScript is painted as “JS with type hints”. Coming from Python background, TS and Python with type hints are just so different. With Python I can’t see myself type-annotating everything (or bringing in pydantic anymore for that matter, it is indeed becoming a blight), but with TypeScript my process is turned on its head: I find it natural and easy to start writing with types and have e…

I've only used Mypy so maybe I should try some more typecheckers. But I've found Mypy and the annotations it uses don't get in the way much, and they make function signatures usable as documentation, so they're generally a win. But they do let a lot of incorrect code through that would have been caught by typechecking in e.g. Haskell. Thus the idea of using 5 typecheckers (not serious I hope, but I understand the sentiment).

I hate JS and have wanted to try Typescript. Is it really JS with type hints? I had thought it was really a different language that compiles to JS, like a less hardcore answer to Purescript. I did like what I saw of Purescript but it never caught on.

I feel like Python itself lost its way during the Python 3 transition and now seems declining like Ruby. IDK what to use instead for low-boilerplate projects though. So I still use Python.

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

#215

Post by OutOfHere »

bitwize wrote: post #175
pmontra wrote: post #23

Earlier quoted context omitted.

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.

God, I hope you never touch a production code base with real users. Strong, static typing has won. It is a must for serious software development. The time and money saved in stupid errors that are caught and avoided before the software even runs is enormous. For internal tools and one-off scripts, sure, go nuts with dynamic stuff, but there is no reason to use a dynamic language for code paths that actually make the…

In fairness, Python code with good type annotations is quite maintainable, but well over 90% of Python programmers and managers are unprofessional enough to not care. That's where a statically typed language adds value.

It is important to be able to understand the LLM generated code, often also to edit it by hand at times. Go lang has the middle ground whereby it's understandable with moderate effort while being statically typed with any necessary flexibility.

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

#217

Post by ActorNightly »

VoidWarranty wrote: post #203
ActorNightly wrote: post #198

Earlier quoted context omitted.

Please stop trying to make Rust happen. You guys are reaching SO hard now. There is no way that Rust will be faster than simply specifying tests for an agent to run after it has generated code.

If I had said c++ would that have triggered you less?

No.

The future of coding is english, no matter what way you put it. Many people already at this point are hardly writing code and outputting things that work.

And if you want clean structure, thats accomplished with AI too. You can analyze the code for common structures, identify refactoring opportunities, and map it to code organization guidelines.

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

#218

Post by VoidWarranty »

ActorNightly wrote: post #217
VoidWarranty wrote: post #203

Earlier quoted context omitted.

If I had said c++ would that have triggered you less?

No. The future of coding is english, no matter what way you put it. Many people already at this point are hardly writing code and outputting things that work. And if you want clean structure, thats accomplished with AI too. You can analyze the code for common structures, identify refactoring opportunities, and map it to code organization guidelines.

A compiler is more efficient than an 8 layer llm lasagna stack of tools. Likewise, to stay on topic: a strictly typed language is better than running five python type checkers if you really want type checking.

Its more efficient to have a llm write in a strictly typed language than to duct tape guardrails(either tools or more llm work) after the fact. Depends on what you're building of course. I speak from an industry that ships large executables. (games)

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

#219

Post by strogonoff »

throwaway81523 wrote: post #214
strogonoff wrote: post #182

Earlier quoted context omitted.

I tend to get triggered when TypeScript is painted as “JS with type hints”. Coming from Python background, TS and Python with type hints are just so different. With Python I can’t see myself type-annotating everything (or bringing in pydantic anymore for that matter, it is indeed becoming a blight), but with TypeScript my process is turned on its head: I find it natural and easy to start writing with types and have e…

I've only used Mypy so maybe I should try some more typecheckers. But I've found Mypy and the annotations it uses don't get in the way much, and they make function signatures usable as documentation, so they're generally a win. But they do let a lot of incorrect code through that would have been caught by typechecking in e.g. Haskell. Thus the idea of using 5 typecheckers (not serious I hope, but I understand the sen…

> Is it really JS with type hints? I had thought it was really a different language that compiles to JS, like a less hardcore answer to Purescript.

No experience with Purescript, but otherwise yes, a language with a different feel. Beats Python in my books. Typings do also serve as documentation but errors won’t compile so it’s not just linting. Make sure to use strict mode so it forces you to pay even more attention to types.

I still occasionally use Python, but TypeScript is my go-to currently.

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

#220

Post by vitamark »

brandnewideas wrote: post #141
vitamark wrote: post #11

Earlier quoted context omitted.

There are examples like ORM query builders (something like `User.id == user_id` should not return a boolean, but rather some inspectable query part), multi-value comparisons (e.g. numpy arrays and views which could also be used as masks for indexing) In general, when you get your hands on operator overloading you get a bunch of various quirky applications for each. Some dunder methods have strict runtime-level rules…

That's one of the things I truly didn't get from my (very limited) experience with SQLAlchemy. Why not just have a method like orm.eq(User.id, user_id)? Much more readable.

Probably just the convenience.

Expression `select(User).where(User.id == user_id)` does look simpler and cleaner than `select(User).where(eq(User.id, user_id)))`.

Maybe there is an actual eq function of sorts that allows that, and it's not a life-or-death difference here, but as far as convenience goes, it works well. And typecheckers are good enough to be able to let you know what's the return type.

Post reply on HN