Skip to content
This repository has been archived by the owner on Jan 5, 2024. It is now read-only.

Archiving/moving on #11

Open
studioph opened this issue Dec 19, 2023 · 1 comment
Open

Archiving/moving on #11

studioph opened this issue Dec 19, 2023 · 1 comment

Comments

@studioph
Copy link
Collaborator

I've been putting this off for a really, really long time - as evidenced by the last commit to this repo being over a year and half ago. I wish I could give the cliche excuse of "I don't have the time", but the truth is that since starting this project, my perceptions and opinions on type checking in Python have changed quite a bit, and I no longer believe that this project provides value.

This does not mean that I think beartype or type checking Python code is not valuable, but rather that when I look at what I see are appropriate use-cases for runtime type checking, and the kinds of objects this sort of "shim" library revolves around - to me it doesn't make sense. From where I stand now, I don't think it makes sense to runtime type check objects that aren't coming into your code externally, like a request body or parsed file. My belief is that the things this project helps you type-check at runtime, like AWS SDK client objects, is the kind of thing that should be handled by static type-checkers - to make sure you didn't make a mistake passing arguments incorrectly and the like.

If there is someone (or multiple people) who feel differently, and would like to continue this kind of work, by all means. I will be happy to pass the torch along. If not, I plan on archiving this repository so that a dead project doesn't continue to take up valuable pinned space in the beartype organization.

I'm sorry @leycec, I feel like I failed you. You were so enthusiastic and supportive when I first wandered into the beartype world and I fear that was wasted on me, since I did not grow into the role you'd probably hoped for in this community. That's part of the reason I've pushed this off - I feel embarrassed to be yet another person who started something in the FOSS world just to abandon it so quickly - but my heart just isn't in it. I feel I'm doing a disservice to the beartype community by having this project still up on the pinned repositories when it's clear it's not active. I hope, delay aside, that I'm going about this the right way so that beartype can move forward.

@studioph studioph pinned this issue Dec 19, 2023
@leycec
Copy link
Member

leycec commented Dec 19, 2023

Awwwwwwwwww. You're so amazing, @studioph! Thanks so much for your heartfelt, thoughtful, and fully open ruminations. It was honour to briefly share the same open-source space. I can only hug your GitHub avatar repeatedly.

from me to you
Above: @leycec. Below: @studioph.

I... kinda suspected this might be coming. But I'm so grateful for how you went about this. Of course, I now disrupt this fragile moment in time dripping with sadness and tears in the rain with...

I don't think it makes sense to runtime type check objects

wut u say
shocked cat is shook by this slanderous suggestion

Naturally, shocked cat disagrees. Politely, of course. Shocked cat is nothing if not the consummate gentleman.

Still, @beartype does intend to type-check literally everything: AWS warts and all. If it's an object, @beartype will check it.

From @beartype's perspective as a third-generation hybrid runtime-static type-checker, first-generation pure-static type-checkers like mypy and pyright are already the past. A noble post, to be sure – but the past all the same. @beartype and typeguard already perform both static and runtime type-checking. Once feature-complete, @beartype and typeguard will literally be the superset of mypy and pyright. Everything they do, we can do better. We have Turing on our side.

Linters like ruff and pylint still have a place. Gotta catch those trivial syntactic errors in real-time, right? But... pure-static type-checkers? They're simply wrong about too much and right about too little. They swim in false positives, hallucinated "errors," and willful delusion. I press F to doubt that most of the industry will still care about pure-static type-checkers in a decade or two. I mean, sure, I get it; Microsoft especially has invested too much to simply abandon the Great Project. They'll continue to enable pyright by default. But will anyone care? Or will most devs just quietly disable (or simply ignore) pyright in favour of linters and hybrid runtime-static type-checkers like @beartype?

Python is here to stay. We thank AI for that daily. But... pure-static type-checkers? Their day is passing beyond the event horizon. So say we all:

"Gobble them up, @beartype! Gobble them all!" 😋

Thanks so much again for all the fun, sun, and commits. Our upcoming @beartype 0.17.0 is for you, bro.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants