✧✦Catherine✦✧anyway if you want a python dependency manager not owned by openai, try pdm
bimbo savant (cow arc)@whitequark oh no, what did i miss :/
fyrfaras@imbl @whitequark Astral, the start-up behind uv and other Python tools, got aquired by OpenAI today. Now I'm kinda glad that I didn't invest too much time learning about uv ...
@fyrfaras @whitequark i just saw >:/
yay! im so excited to "sloppercharge my productivity" or whatever!!!
although i do love the irony that astral's repos use claude. really shows how full of shit they are when their announcement is sucking up to openai's codex but they're using a competitor's slop machine. definitely not just showing a complete lack of values lol
Elizabeth 
@imbl @fyrfaras @whitequark not a huge surprise sadly, anyone who’s used Python has seen this coming ever since the big data then the LLM researchers got interested in Python.
@whitequark @Elizafox @fyrfaras mmmmmm type-safe slop
ive used mypy enough to know that this is going to fail hilariously the first time it encounters wrong or poorly-typed interfaces >:3c
@whitequark @Elizafox @fyrfaras fully agree. mypy sucks but its what i learned and its got all the plugins, plus i never got pyright working
i was actually planning on switching to ty for my next project 
@whitequark @imbl @Elizafox I sea, could you please elaborate why mypy is a net negative for programming? ^_^
@whitequark @fyrfaras @imbl I like mypy but I get some people prefer Python to be properly dynamically typed (that’s fine too).
@Elizafox @whitequark @imbl Alrighty, thank you for explaining it to me. ^^ Also I just read a toot thread, below, by @xgranade that mypy doesn't use “mathematical type checking” but rather “linting heuristics” which could lead to this bad reputation you've mentioned earlier I think.
Cassandra is only carbon now (@[email protected])
As I mentioned earlier, it's a bit more difficult to have good exit strategies with ruff, given that the specs around linting are much more loose. It's even harder to have a good exit strategy for ty, even though there's good specs, because there's not a great type checker to use instead¹. ___ ¹As has been pointed out to me, mypy is, for all its strengths and weaknesses, not a type checker. It doesn't follow formal mathematical type checking rules, it follows linting heuristics.
Cassandra is only carbon now@fyrfaras @Elizafox @whitequark @imbl Like, I'm not trying to be petty or sarcastic about it. Rather, it's that I think some of my earlier (and admittedly a bit toxic) hate of mypy came from deeply misunderstanding what mypy is and is trying to do. I would have expected from docs and the description, that mypy accepts well-typed programs and rejects programs that violate typing rules — but that's not it. It rejects well-typed programs that are likely incorrect, which is what a linter does.
@fyrfaras @Elizafox @whitequark @imbl In particular, I cannot predict the behavior of mypy given knowledge of Python's type system alone. I have to know about what is and is not likely a logic error in Python.
Which is fine if you want a somewhat more rigorous linter that has the benefit of being developed under the auspices of the PSF itself. But it's not what I want or would want out of a type checker.
@whitequark @fyrfaras @Elizafox @imbl Agree, absolutely.
I made the mistake of thinking of it as one for a long time, but I have been disavowed of that notion.
@xgranade @fyrfaras @Elizafox @imbl however the problem is that the mypy website has this misinformation on the landing page
@whitequark @fyrfaras @Elizafox @imbl Ooof, yeah. Were I in the mood to start useless fights, I'd be tempted to PR a change to that page, but it'd just get people hurt for no reason.
I mean, it just isn't a type checker. That's not what it does.
@whitequark I guess part of it is that I'm trying to reconcile "cool people that I think well of work on mypy" and "mypy is manifestly unfit to serve as the thing it advertises itself as." For me, that comes down to trying to understand what mypy *is* for if it's not the thing it's billed as, if there's some kind of semantic drift there.
Were I to make that PR as a frequently loud critic, I don't think it'd come across in good faith, and, well, fair enough.
@xgranade well. how to put it. I don't care how it's fixed, just that it is
@whitequark That's completely fair.
Glyph@xgranade @whitequark I'm still not really clear on why the incorrect simplifying assumptions about python's runtime that ty makes are just the practical compromises of a sound type checker but the incorrect simplifying assumptions that mypy makes put it in an entirely different category of software
@xgranade @whitequark like "too much busywork for the amount of bugs it finds" is not an experience I have had, but we write very different kinds of code so I'm definitely not arguing with that; I could see that 'ty' or 'pylance' might do far better with your code, or might even have a more rigorous approach to certain aspects of their type algebra. but all three happily give this program (and many like it) the thumbs-up:
x = 1
y = 2
locals()['y'] = 'oops'
print(x + y)
@whitequark @xgranade this is actually why I prefer mypy, specifically because (via plugins) it can accept an extension to the type system implemented with runtime hackery, and handle Zope Interface, while none of the other ones can. pydantic also has a similar thing (and dataclasses were originally supported via the 'attrs' plugin, although everybody else eventually got on board with those).
but I guess when it comes to "helpful" warnings, mypy probably does produce a lot more of those
@whitequark @xgranade in any case, I absolutely understand “the experience of using this sucks”, I just don’t get the category distinction
@whitequark @glyph Sorry, was on a StS2 run, heh. Anyway, my understanding of the difference is that sometimes, when you report a false negative in mypy (that is, a program being rejected despite being well-typed), the response is "well, don't write that program." I struggle to put into words how off the mark that is for a type checker, but it's perfectly sensible for a linter.
Alyssa Coghlan@xgranade @whitequark Would "type aware logic checker" be a more accurate description of what it does?
@ancoghlan @whitequark @glyph suggested "type aware linter" in another branch, and yeah, I think that's much more instructive, and would have reduced a lot of frustrations for me trying to understand what was going wrong.
@xgranade @ancoghlan @whitequark so I don't think that turning off these warnings *by default* is going to fly (clearly the maintainers feel that they're useful, or they wouldn't be WONTFIX'd), but I wonder if a "--types-only" mode could be added? ty and pyright have a bunch of lints but they have this error/warning distinction that mypy doesn't. modulo possibly a few undocumented [misc]s it seems like the distinction on the behavior of these checks is pretty clear
@ancoghlan @xgranade from a distance that sounds reasonable (also non-committal but i have no issues with that here)
@xgranade @whitequark @fyrfaras @Elizafox i really love this thread because subconsciously i'd categorized mypy as a linter a loooong time ago but consciously i've always treated it as a type checker. it makes so much more sense as a linter though, i feel like a puzzle piece just clicked into place haha
@imbl @xgranade @fyrfaras @Elizafox fittingly, i aggressively avoid linters as an approach to making software because i think they mostly create performative busywork
(i use the software tools that call themselves linters, sometimes, configured in a very careful way that mostly avoids this problem. my list of ruff rules is like 300 lines long and it is strictly opt-in, for example)
@whitequark @xgranade @fyrfaras @Elizafox i should really start doing that, most of my fun projects die when i have to fix linter warnings
@whitequark @xgranade @fyrfaras @Elizafox any chance that config is online anywhere so i can yoink it? 