dcreager

6 ms·

1.
by dcreager 6mo ago
Does that not also suggest (cautious, make sure we back it up with our actions) optimism about this acquisition? We're not breaking up the band. These tools will be in the same hands as before. And it would be extremely value-destructi
2.
by dcreager 6mo ago
The parser is not the hard part. The hard part is doing something useful with the parse trees. They even chose "oh is that all?" and a picture of a piece of cake as the teaser image for my Strange Loop talk on this subject! https
3.
by dcreager 6mo ago
I've been in the industry for similarly long, and I understand and sympathize with this view. All I can say is that _right now_, we're committed to maintaining our open-source tools with the same level of effort, care, and attenti
4.
by dcreager 6mo ago
> I hope this means the Astral folks can keep doing what they are doing, because I absolutely love uv (ruff is pretty nice too). That is definitely the plan!
5.
by dcreager 6mo ago
> My understand is Astral's focus for ty has been on making a good experience for common issues, whereas they plan for very high compliance but difficult or rare edge cases aren't are prioritized. I would say that's true i
6.
by dcreager 6mo ago
Can you elaborate what you mean by decorative? If you run a type checker like ty or pyright they're not decorative — you'll get clear diagnostics for that particular example [1], and any other type errors you might have. You can s
7.
by dcreager 6mo ago
There have been some early proposals to add something like that, but none of them have made it very far yet. As you might imagine, it's a hard problem!
8.
Give Django your time and money, not your tokens(better-simple.com)
442 points by dcreager 6mo ago|171 comments
9.
by dcreager 9mo ago
There was a hang/performance bug [1, 2] that was reported just after the beta release, which we've since fixed [3]. You might try seeing if we get through your entire project now? (And as an aside, there _is_ a verbose mode: if yo
10.
by dcreager 9mo ago
Yes, we love TypeForm! We plan to support it as soon as the PEP for it lands. Under the covers, we already support much of what's needed, and use it for some of our special-cased functions like `ty_extensions.is_equivalent_to` [1,2]. T
11.
by dcreager 9mo ago
And the PEPs are now collated into a larger single typing spec [1], even hosted on a python.org subdomain. (Previously it was hosted on readthedocs) [1] https://typing.python.org/en/latest/
12.
by dcreager 11mo ago
Stepping away from Forth in particular, one of the benefits of a stack-based / concatenative language is that it's easy to implement on constrained hardware. uxn [1] is a great example of that. And shameless self-promotion, if you
13.
by dcreager 1y ago
> competing with PyPI pyx doesn't compete with PyPI; it's a private registry that companies can use e.g. to host internal-only packages, or to provide curated views of things like PyPI for compliance reasons. > making change
14.
by dcreager 1y ago
The Open Firmware bootloader also used a Forth as its command-line interface. That was used on PowerPC Macs before Apple switched over to Intel. (So, you know, two processor architectures ago.) A common theme is that Forth-likes are very ea
15.
by dcreager 1y ago
That's okay, it's a fun thing to do!
16.
by dcreager 1y ago
I think that's a genuine error, since as you say, `None` is a possible value for `b` according to your signature. To handle this you would need to use "narrowing" to separately handle the case where `b` is `None`, and the cas
17.
by dcreager 1y ago
Well ours is not yet implemented, so it's too early to say whether they're compatible. :-) But less snarkily, we do talk to them often (and the authors of other tools like mypy and pyright) to make sure we aren't introducing
18.
by dcreager 1y ago
The current plan is that they will remain separate tools, but will work together nicely if you are using both. For instance, we want to add type-aware and multi-file lints to ruff at some point down the line.
19.
Concatenative programming and stack-based languages (2023) [video](youtube.com)
15 points by dcreager 1y ago|1 comments
20.
by dcreager 1y ago
It really helps in our mdtests, because then we can assert that not-implemented things are currently wrong but for the right reasons!
21.
by dcreager 1y ago
I don't know that I'd want the scripting language to be compiled, for reasons that are outside the scope of this reply. So removing that constraint, the coolest thing I've seen in this space recently is kyren's Piccolo:
22.
by dcreager 1y ago
ty is definitely not ready to be a pyright replacement yet. But it is usable as an LSP for simple things like go to definition, and deeper LSP features are on the roadmap for the eventual beta and GA releases. https://github.co
23.
by dcreager 1y ago
> I hope I didn't come off as angry or anything, I was just very surprised by the behaviour Not at all! :-) Just wanted to clarify for anyone else reading along
24.
by dcreager 1y ago
> Gradual typing means that an implicit "any" (unknown type) anywhere in your code base is not an error or even a warning. Even in critical code you thought was fully typed. Where you mistakenly introduce a type bug and due to
25.
by dcreager 1y ago
[ty developer here] We are happy with the attention that ty is starting to receive, but it's important to call out that both ty and pyrefly are still incomplete! (OP mentions this, but it's worth emphasizing again here.) There are
26.
by dcreager 1y ago
> I am strongly against ty behaviour here. [ty developer here] Please note that ty is not complete! In this particular example, we are tripped up because ty does not do anything clever to infer the type of a list literal. We just infer `
27.
by dcreager 1y ago
Note that we're not ever spinning up a Python interpreter to run your code, or monitoring an existing running Python process. So we do need some kind of metadata. But yes, if you have a Python version specified in pyproject.toml, we
28.
by dcreager 1y ago
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
29.
by dcreager 1y ago
We're definitely thinking hard about the ergonomics of our error messages! We're drawing inspiration from rustc and miette for the diagnostic model, and are aiming for a quality bar on par with rustc for their content.
30.
by dcreager 1y ago
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 i

More ›