On Fri, 14 Oct 2022 at 19:36, Christopher Barker <pythonchb@gmail.com> wrote:
I’m sorry that my typing-skepticism came across too strong, but while the tone and language revealed my personal view, I still think the points were correct.
Paul: I didn’t say annotations were experimental. I said “static typing” is — and I really think it still is, though “immature” is a better word.
I don't know that I'd agree with you, but it's not that important, as static typing isn't (and will never be) something provided by (core) Python.
Better evidence than the multiple implementations is the still unsettled state of PEP 563 and the number of typing-related PEPs introduced in the last few Python releases.
Fair. There *is* a lot of change. But "experimental" for me has a more negative implication than simply a rapid pace of change. As I say, it's not that important though.
My point stands: Static type analysis tools are not stable enough at this point to choose an “official” one.
My point is that we shouldn't *ever* expect to choose an official tool. Diversity is good and there's multiple (not entirely compatible) use cases. It's not the job of the stdlib (or "Python") to pick one library over another. Libraries get to be in the stdlib because the *community* chooses them. And in this case, probably not even then (see below). I guess we may be agreeing here. But I wasn't certain from your comments who you were expecting to do the "choosing" - it felt like you expected the stdlib/core devs to make the call, but if I got that wrong, then fair enough.
But Paul’s point is better- This kind of development tool doesn’t belong in the stdlib at all — the features that are needed to support static type checkers do, which is why they have been added (and still are), but not the tool(s) itself.
And I’m confused about your point about my directing my typing rants at the Core devs— this is Python ideas, not Python-dev, and a community member suggested that Static Type analysis be standardized— how was my response not directed at the community ?
Your comments that static typing is experimental felt like they were directed at the core devs, and your overall skepticism about typing (some of which I share, to be clear) feels very much like you want *less* type annotation support in the stdlib/core, not that you think what's there is about right and community members need to understand that "in the core" doesn't equate to "mandatory". On the contrary, you give the impression that you *already* feel that typing is being forced on people who don't want it - by the language and the core devs, not by the community. If you'd addressed the suggestion that static type analysis be standardised by saying "Python has a clear policy that type annotations are optional, and checking will never be enforced by the language, so standardising a specific type checker isn't really appropriate" then that would have felt much more clearly directed at the community. But whatever, you're entitled to your opinions, and you're entitled to express them how you wish, so I don't want to dissect your wording and read things into it that you didn't intend. Sorry if I did so.
And your example of PEP 8 is an excellent one: PEP 8 is a style guide for the standard library itself. But that gives it a perceived endorsement as an all-Python standard — I’m suggesting that we wouldn’t want to accidentally provide a similar perceived endorsement of a particular static type checker.
I'd go further and say that we (by which I mean "the Python community") should work hard to oppose any drift towards the sort of corrosive insistence that everyone "must" follow rules, or use tools, that are intended as guidelines and helpers, which surrounds the whole "PEP 8 compliance" idea. And in particular, we should push back hard on a similar mindset taking hold regarding type annotations. Paul