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

271–280 of 296 posts

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

#271

Post by johnfn »

smithkl42 wrote: post #81
johnfn wrote: post #27

Earlier quoted context omitted.

In defense of mypy et al, Typescript had some of the greatest minds of our generation working for a decade+ on properly typing every insane form found in every random Javascript file. Microsoft has funded a team of great developers to hammer away at every obscure edge case imaginable. No other python checker can compare to the resources that TS had.

And in the process, they ended up creating an extremely powerful type system that ~nobody outside of that original team can (fully) understand.

How many people understand the intricacies of any complex language or type system? Though I think one of the great things about TS is that you need to understand none of it in order to do `npm install @types/lodash` and get all the benefits.

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

#272

Post by mahogany »

johnisgood wrote: post #242
lacasito25 wrote: post #217

Earlier quoted context omitted.

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

How is it condescending in any way? I found it to be a constructive criticism; i.e. useful help.

I don't necessarily read it as condescending, but I do read it as presumptuous. What someone "should" do depends on many things. Maybe, because this is software in alpha stage, they should _not_ focus on this part of the code if it is minor compared to other obligations. Or maybe there are other reasons they've chosen not to do this (as was explained in an above comment).

IMO, a less presumptuous criticism would be phrased like "if you did X then benefits Y would happen", or "if you haven't, consider X", or even (the least presumptuous - make it a conversation!) "have you considered X?", rather than "you should do X".

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

#273

Post by 0xffff2 »

dcreager wrote: post #255
HelloNurse wrote: post #205

Earlier quoted context omitted.

Defaulting is wrong: what is checked is the aggregate of actual user code, standard library for a given Python version and installed packages. It has to be the same environment as when the program is run, leaving conservative approximations (checking types with the oldest supported library versions and hoping newer ones are OK) to the user.

Yes, if you have a Python version specifed in pyproject.toml, for instance, we respect that, and that's what we use to type-check your code. The default being discussed here is what we fall back on if that project metadata isn't available.

Could you check what version of `python` is in the PATH and use that as the default?

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

#274

Post by theLiminator »

digdugdirk wrote: post #248
_carljm wrote: post #128

Earlier quoted context omitted.

Yes, we've talked; I know a number of the pyrefly devs well. Ty had already been months in development when pyrefly development started. We discussed collaboration, but they decided they needed to do their own thing in order to move quickly and ensure it would serve their needs, which is totally reasonable.

It looks like both projects seem to use Ruff at their core, is there any documentation that describes the differences in each project's approach?

I believe the only sharing is parsing/ast.

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

#275

Post by Sarios »

dcreager wrote: post #258
Sarios wrote: post #168

Perhaps a silly question. Will ty be usable for getting semantical completions / suggestions. Similar to using pyright to get completions based on what's being written.

We are planning on shipping an LSP front end, and the goal is for that to include code completions. Though to set expectations, they will probably not be that sophisticated on day one. There's a lot of interesting work that we could do here, but it will take time!

You guys take your time and enjoy yourselves :). You have a proven record of making good tools, so if this part takes a while, let it take a while.

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

#276

Post by maleldil »

miki123211 wrote: post #160
mjr00 wrote: post #23

Earlier quoted context omitted.

> The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code. Or in this case, writing it in Rust... mypy is written in Python. People have forgotten that Python is really, really slow for CPU-intensive operations. Python's performance may not matter when you're writing web service code and the bottlenecks are database I/O and network calls, but for a tool that's…

Python is slow for some CPU-intensive operations. There are some extremely CPU-intensive low-level operations that you can easily write in C and expose as a Python API, like what Numpy and Pandas do. You can then write really efficient algorithms in pure Python. As long as those low-level operations are fast, those Python-only algorithms will also be fast. I don't think this is necessarily "cheating" or "just calling…

> As long as those low-level operations are fast, those Python-only algorithms will also be fast.

Only if you spend more time on the C implementations than on Python. If you have pure Python loops, you'll be slow. You need quite high-level components and minimal Python glue for it to be fast.

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

#277

Post by maleldil »

networked wrote: post #252
dathinab wrote: post #83

Earlier quoted context omitted.

It's even worse (for python). TS might transpile to JS and can always be split into a js and type annotation file but is it's own language developed in tandem with the type check based on a holistisch approach to find how to type check then and then put it into the syntax and type checker. Thats not true for python at all. Python types where added as annotations to the language many years ago, but not in a holistic a…

Why do you say that duck typing is simplified structural typing? Its relationship with structural typing is on a different axis. Duck typing is its dynamic-typing counterpart. Python does support structural typing through protocols introduced in version 3.8. They are documented in https://typing.python.org/en/latest/spec/protocol.html . As a demo, here is part of https://www.typescriptlang.org/play/typescript/languag…

If I understand correctly, defining the protocol like this forces the implementation classes to have the members as proper fields and disallows properties. If you define `diameter` as a property in the protocol, it supports both:

    from dataclasses import dataclass
    from typing import Protocol

    class Field(Protocol):
        diameter: float


    class Property(Protocol):
        @property
        def diameter(self) -> float: ...

    class Ball:
        @property
        def diameter(self) -> float:
            return 1

    @dataclass
    class Sphere:
        diameter: float

    ball_field: Field = Ball()
    sphere_field: Field = Sphere(diameter=20)

    ball_prop: Property = Ball()
    sphere_prop: Property = Sphere(diameter=20)
Pyright output:

    /Users/italo/dev/paper-hypergraph/t.py
      /Users/italo/dev/paper-hypergraph/t.py:27:21 - error: Type "Ball" is not assignable to declared type "Field"
        "Ball" is incompatible with protocol "Field"
          "diameter" is invariant because it is mutable
          "diameter" is an incompatible type
            "property" is not assignable to "float" (reportAssignmentType)
    1 error, 0 warnings, 0 information
That is to say, I find Python's support for structural typing to be limited in practice.

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

#278

Post by maleldil »

Spivak wrote: post #213
surfingdino wrote: post #194

Earlier quoted context omitted.

What annoys me is that every programmers who wish their favourite language / feature was as popular as Python and they choose to implement it in Python to make Python "better". Python was created as a dynamically typed language. If you want a language with type checking, there are plenty of others available. Rust devs in particular are on a bend to replace all other languages by stealth, which is both obviously visib…

This argument doesn't make a whole lot of sense because nothing about type annotations constrains Python code at all. In fact because they're designed to be introspectable they make Python even more dynamic and you can do even crazier stuff than you could before. Type checkers are working very hard to handle the weird code. Pydantic being so fast because it's written in Rust is a good thing, you can do crazy dynamic…

> nothing about type annotations constrains Python code at all

Sorry, but this is just not true. Don't get me wrong, I write typed Python 99% of the time (pyright in strict mode, to be precise), but you can't type check every possible construct in the language. By choosing to write typed Python, you're limiting how much of the language you can use. I don't think that's a bad thing, but it can be a problem for untyped codebases trying to adopt typing.

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

#279

Post by maleldil »

bvrmn wrote: post #134
johnfn wrote: post #27

Earlier quoted context omitted.

In defense of mypy et al, Typescript had some of the greatest minds of our generation working for a decade+ on properly typing every insane form found in every random Javascript file. Microsoft has funded a team of great developers to hammer away at every obscure edge case imaginable. No other python checker can compare to the resources that TS had.

It's not mypy issue. Comparing to TS python typehints (spec wise) are a joke. It's started as bolted on adhoc solution and evolved quite chaotically. For example [1]. TS doesn't require a special decorator (sic!) to make your custom classes to be picked up by type checkers. Or how make a wrapper function with args and kwargs to pass through? [1]: https://docs.python.org/3/library/typing.html#typing.datacla...

The dataclass decorator isn't there to make the type checkers understand the class. Its main purpose is to automatically implement trivial methods like the constructor, equality, repr, etc. The type hints make this more convenient, but something similar already existed with attrs.

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

#280

Post by Tryk »

dcreager wrote: post #256
lemontheme wrote: post #198

Earlier quoted context omitted.

From what I’ve gathered (because I had similar concerns), the code is properly open source. In the very worst case, should there ever come a rug pull, it can be forked.

The code is definitely open source from a licensing perspective, but we are also trying to ensure that a healthy community forms around our tools as well. We've been developing ty in the open for the last year or so, and it already includes significant work from external contributors. This is definitely not a project where only Astral-paid engineers can contribute.

That's cool. So can you elaborate on how your long-term profitability is projected? Of course there would not be too much point in contributing to a project that gets aggressively monetized in the near future.
Post reply on HN