251–260 of 296 posts
Not the most fun question, but as I see Astral taking over the python ecosystem, I can't help but wonder: how do y'all plan to make money? It seems like you've taken VC funding, so monetization is inevitable.
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 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…
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/language/stru... translated to Python:
from dataclasses import dataclass
from typing import Protocol
class Globular(Protocol):
diameter: float
class Spherical(Protocol):
diameter: float
# In Python, we need to define concrete classes that implement the protocols.
@dataclass
class Ball:
diameter: float
@dataclass
class Sphere:
diameter: float
ball: Globular = Ball(diameter=10)
sphere: Spherical = Sphere(diameter=20)
# These assignments work because both types structurally conform to the protocols.
sphere = ball
ball = sphere
class Tubular(Protocol):
diameter: float
length: float
@dataclass
class Tube:
diameter: float
length: float
tube: Tubular = Tube(diameter=12, length=3)
tube = ball # Fail type check.
ball = tube # Passes.
Found 1 error.
/scratch/structural.py
/scratch/structural.py:37:8 - error: Type "Ball" is not assignable to declared type "Tubular"
"Ball" is incompatible with protocol "Tubular"
"length" is not present (reportAssignmentType)
1 error, 0 warnings, 0 informations
error: lint:invalid-assignment: Object of type `Ball` is not assignable to `Tubular`
--> structural.py:37:1
|
35 | tube: Tubular = Tube(diameter=12, length=3)
36 |
37 | tube = ball # Fail type check.
| ^^^^
38 | ball = tube # Passes.
|
info: `lint:invalid-assignment` is enabled by default
Found 1 diagnosticEarlier 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.
So if we were to do this for ty, we would have to carefully design the internal data types and algorithms that we use to model Python code, so that they're extensible in a robust way.
But we would also have to decide what kind of Rust plugin architecture to use. (Embed a Lua interpreter? dlopen plugins at runtime? Sidecar process communication over stdin/stdout?)
Solvable problems, to be sure, but it adds to the amount of work that's needed to support this well — which in turn affects our decisions about whether/when to prioritize this relative to other features.
Earlier quoted context omitted.
Pointlessmy anal; but 0.0.0a6 is very strongly indicative of the sixth alpha release. Pre-alpha are much better as .dev releases.
It is the sixth alpha release. They haven't yet released a stable version – this is their sixth alpha release before that. What am I missing here?
Earlier quoted context omitted.
(ty developer here) Currently we default to our oldest supported Python version, in which `datetime.UTC` really doesn't exist! Use `--python-version 3.12` on the CLI, or add a `ty.toml` with e.g. ``` [environment] python-version = "3.12" ``` And we'll find `datetime.UTC`. We've discussed that this is probably the wrong default, and plan to change it.
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.
Awesome work. What is the business model for these astral tools? It’s a bit of a “waiting for the other shoe to drop” feeling after seeing the VC backing on the company page.
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.
I am literally checking HackerNews while I wait for mypy to finish running, so I am excited to hear a faster type checker is on the way! Hope the error messages are also helpful.
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.
Earlier quoted context omitted.
Fingers crossed this isn't a joke.
Well, it is a joke...but that said, we're hosting a happy hour which is kinda similar! https://partiful.com/e/Dcrv6XA8PjWTK5Zhw8yr
Now, I know you folks haven't ever done that, but it is such a pattern lately that I almost expect it from any for profit company whose primary product is open source. I don't want to judge you based on the actions of others... but the pattern is so well established now that I have to exercise caution.
Now, in the end, I simply switch to whatever open source fork or alternative crops up (or already exists). But it makes it hard for me to go "Hey everyone, you should be using Astral's X because they are awesome and X is awesome and X is open source. And do 'y'[code contributions, financial sponsorship, buy support from them- whatever it might be] to make sure to support Astral and their development of the open source X code!" ... because I am anticipating the rug pull, taking the trademark and brand down the tube with it. Yet, I really, really, really want to support you folks. I want to tell everyone about your great products. I want to encourage them to use your product and to support you financially.
Earlier quoted context omitted.
> such as claiming `datetime.UTC` doesn't exist) This is a known issue — we're currently defaulting to a conservative Python version, and `datetime.UTC` really doesn't exist until Python 3.11! https://docs.python.org/3/library/datetime.html#datetime.UTC We will probably change the default to "most recent supported Python version", but as mentioned elsewhere, this is very early and we're still working out these kinds…
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.
But yes, if you have a Python version specified in pyproject.toml, we respect that, and if you have a virtualenv, we can see the Python version that was used to create 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.