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

Ty: A fast Python type checker and language server

github.com

Post reply on HN
Print view View original

221–230 of 296 posts

Re: Ty: A fast Python type checker and language server

#221

Post by 9dev »

reubenmorais wrote: post #203
davedx wrote: post #179

Earlier quoted context omitted.

What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages. For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's ju…

This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported. Ty could solve this if they rebel and decide to ignore the Python typi…

Python code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example.

I loathe the Python convention of just using kwargs instead of clearly annotated parameters; most libraries don't even have doc comments in the code, so you're really required to look up the documentation, hope that it actually describes the method you're interested in and contains more than stuff like "foo: the foo to use"—or fall back to rummaging in the library intestines to figure out how it works.

It's pathetic.

Re: Ty: A fast Python type checker and language server

#222

Post by kmacdough »

nickagliano wrote: post #10

Interesting to see astral come out with this right around facebook’s release of “Pyrefly, a faster Python type checker written in Rust”. Not making any sort of ethical statement, just interesting that rust keeps eating the python and JS tooling worlds.

Yes, because this is precisely what rust has proven it is exceptional for: tooling that needs to be very correct and strives to be fast.

Re: Ty: A fast Python type checker and language server

#223

Post by 9dev »

globular-toast wrote: post #211
bootsmann wrote: post #206

Earlier quoted context omitted.

Only tangentially related but does anyone else here get very bothered when looking at the SQLAlchemy documentation? It seems so hard to find what kind of magic incantation you need to do in which order when trying to do a somewhat non-trivial query and I often just write the SQL I want and then tell chatGPT to rewrite it to SQLAlchemy operations but thats not really a sustainable solution.

Have you sat down and read the SQLAlchemy docs properly? It made a lot more sense to me once I'd set aside an hour or two to work through the Unified Tutorial.[0] I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy. If you know the SQL you want it's just a matter of writing it in SQLAlchemy's query language which is quit…

> I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy.

Good documentation should absolutely provide a usable reference to quickly look up common ways to solve common problems. Even the PHP docs got that right twenty years ago.

Also, I disagree: A library should be as self-evident and incrementally understandable as possible, not require reading a full tome and grow a grey beard before being accessible.

> "Complex queries" usually turn up when you're doing something like rendering a table or report or something. You don't need the ORM for this kind of thing, just write a query.

Or, when building generic filtering/sorting/pagination logic for a bog-standard CRUD app. Or to do full-text search. Or when doing lateral joins to minimize queries. Or to iterate over a huge table. There's lots of cases where I want the ergonomics and malleability of ORM query instances even when working with complex queries.

Re: Ty: A fast Python type checker and language server

#224

Post by lionkor »

lacasito25 wrote: post #217
zo1 wrote: post #187

Earlier quoted context omitted.

You should be doing this dynamically based on the version of python you are running against, so that you don't have to hardcode or make such "conservative" choices by hand.

I think they probably know that, this is alpha software, no need to be condescending.

They said they will default to some newer version, which indicates they are not planning to do this dynamically.

Re: Ty: A fast Python type checker and language server

#225

Post by badmintonbaseba »

jez wrote: post #163
tyrion wrote: post #124

Earlier quoted context omitted.

Helping improve the spec and all is great, but being 100% honest, as a user, I would rather have a type checker I can bend to my needs. As you said, some code patterns in a dynamic language like Python are difficult, or even impossible, to type-check without custom code. Type checkers are becoming more popular than ever, and this implicitly means that these code patterns are are going to be discouraged. On one hand,…

Out of curiosity, do you have experience with other languages that have type system plugins that you’d hope be used as inspiration for something in Python? I don’t have any such experience (short of a macro system, which requires code generation or runtime support) and it always makes me curious when people ask for type system plugins whether this is a standard feature in a type system I’ve never used.

Isn't mypy extensible with plugins?

Re: Ty: A fast Python type checker and language server

#226

Post by anentropic »

WhyNotHugo wrote: post #86
notatallshaw wrote: post #67

Earlier quoted context omitted.

Charlie already said in a podcast ( https://www.youtube.com/watch?v=XVwpL_cAvrw ) that they are not looking to make it extensible. That it's considered a feature that type checking works interchangeably across tools and projects. Ruff's linting and formatting is more likely to get plugin/extension support at some point in the future.

I wonder how they'll handle situations like Django, which don't seem expressible via stubs.

I love Django, but maybe Django should change more from their side? e.g. Django 6?

Re: Ty: A fast Python type checker and language server

#227

Post by tinodb »

globular-toast wrote: post #211
bootsmann wrote: post #206

Earlier quoted context omitted.

Only tangentially related but does anyone else here get very bothered when looking at the SQLAlchemy documentation? It seems so hard to find what kind of magic incantation you need to do in which order when trying to do a somewhat non-trivial query and I often just write the SQL I want and then tell chatGPT to rewrite it to SQLAlchemy operations but thats not really a sustainable solution.

Have you sat down and read the SQLAlchemy docs properly? It made a lot more sense to me once I'd set aside an hour or two to work through the Unified Tutorial.[0] I feel like these days people just want quick answers to do very specific things but that's a very inefficient way to learn something like SQLAlchemy. If you know the SQL you want it's just a matter of writing it in SQLAlchemy's query language which is quit…

Exactly the reason I stay away from it. I prefer just SQL and something like aiosql to load it.

Re: Ty: A fast Python type checker and language server

#228

Post by badmintonbaseba »

amelius wrote: post #220
lyu07282 wrote: post #132

Earlier quoted context omitted.

The CPython API is such a dumpster fire, even writing very simple modules the reference counting is very difficult to do correctly. The majority of python modules written in C are probably leaking memory somewhere but nobody knows.

My problem is that debugging a segfault in a Python system is impossible because of all the noise generated by Python modules that never bothered to clean up their Valgrind output.

Some tricks that worked for me in the past:

1. use rr for debugging your binary wheel, you can set up watchpoints, and reverse step/continue from the segfault.

2. compile and run your wheel with sanitizers (ASAN, UBSAN).

I rarely use valgrind so I can't comment on that.

Re: Ty: A fast Python type checker and language server

#229

Post by anentropic »

nindalf wrote: post #177
preciousoo wrote: post #146

Earlier quoted context omitted.

CI/CD products most likely, or something more futuristic in that line

CI/CD, private repositories, providing hosting. These are the options used by similar companies. But I like that they’re focussing on creating something useful before chasing revenue. Once they’ve got a single tool that provides a consistent dev experience for Python developers and it’s widely adopted they should be able to pursue monetisation easily.

"Step 3: profit!"

Re: Ty: A fast Python type checker and language server

#230

Post by Philpax »

rc00 wrote: post #166
urbandw311er wrote: post #70

It’s like when we hit a new month the quota of “talk about Rust” credits is renewed.

The timing of the recent batch of propaganda makes it hard to believe it's not coordinated. I wouldn't suggest paid actors but maybe just an attempt to counter some fairly visible and negative recent takes. The amount of "I love Rust but" comments make it hard to take the commentary seriously too.

Is it really that hard to believe that people like the language and the problems it solves for them?
Post reply on HN