A more useful and less divisive future for typing?

We don’t have a fence, but we do have a shed: GitHub - python/typeshed: Collection of library stubs for Python, with static types
If a library doesn’t wish to add type annotations, but is facing pressure from users to add them, a reasonable compromise is that anyone can contribute stubs containing annotations to typeshed where they can live separately.

Over the years, I’ve read several posts in this vein, and it’s always unclear to me how much they’re speaking from abstract fear vs concrete experience. If it’s the latter, I’d love to have a more constructive conversation about those experiences.

10 Likes

We don’t have a fence, but we do have a shed:
GitHub - python/typeshed: Collection of library stubs for Python, with static types If a library doesn’t wish to
add type annotations, but is facing pressure from users to add
them, a reasonable compromise is that anyone can contribute stubs
containing annotations to typeshed where they can live separately.

Over the years, I’ve read several posts in this vein, and it’s
always unclear to me how much they’re speaking from abstract fear
vs concrete experience. If it’s the latter, I’d love to have a
more constructive conversation about those experiences.

A decade+ old (but still very actively developed) million-line
codebase I help maintain had some contributors eager to typify it a
few years ago. I and other maintainers were skeptical but were won
over by claims that it would make things more maintainable and
newcomer-friendly, so agreed to the experiment.

For typing to be at all useful, large swaths of the codebase had to
be refactored. The resulting changesets were massive, perpetually
merge-conflicting with the branch state every time something new
merged, and causing many other pending changes to merge-conflict as
soon as a new chunk of typing changes landed. Before any significant
progress was made, behavior changes in mypy meant that the work
which had been merged needed to be redone.

The community around the software in question is only relatively
tolerant of linters on a good day, with an overall view that having
working code is more important than making sure every last thing
about how it’s written is consistent. Needless to say, a constantly
shifting target for what typing should mean resulted in maintainers
feeling they were spending more time reviewing and dealing with
no-op changes to the code than doing productive development.

The contributors who were attempting the sisyphean task of typing
the entire codebase finally got bored, as people chasing whatever
the latest new-shiny tend to, and this experiment ended in
incompletion. The project declared it a failure, and is in the
process of “cleaning up” any typing-related content whenever a file
with some still in it gets new edits. We determined that if people
come along in the future trying again to convince us the code should
be typed, we’ll recommend they put any typing they want to apply in
separate files and update it themselves whenever the software
changes so we won’t have to deal with it.

I’m sure typing is useful for new projects without a lot of
established code, but trying to retroactively apply it to a large
project that wasn’t written with the expectation of being typed
seems to be a major pain-point. At least, that’s my experience.

5 Likes

I generally agree with these comments. There are lots of independent threads that seem to generally be talking about the same thing and they are moving fairly quickly. It makes it hard to keep track all of the comments and what is the actual focus of each thread.

There is no doubt that when type annotations were added, they were optional. And from “the languages” perspective, they are not required for code to run. However, since then standard library features have been added that use/support them (ex: dataclasses & singledispatch). Additionally, some libraries have started using them as a way to control the runtime behavior of the libraries. There has been growing momentum in the larger ecosystem that type annotations are beneficial and should be further improved [1].

This is where we diverge. Maybe this is because we have had different career paths. I started around when 3.1 was released, but was using 2.7 [2]. Since then, I’ve used a variety of languages, both dynamic (javascript & lua) and static (java & c++). But python has been the majority of my career.

In that time, the vast majority of the code I’ve written in dynamic languages has been dynamic in name only. The times I’ve really taken advantage of the awesome amount of flexibility python gives you, it has either been:

  • hidden away underneath an abstraction layer
  • a less formal form of coding to an “interface”

Type annotations allows me to:

  • document the expectations of what my code expects to be passed and will return
  • more easily understand the libraries that my code uses.
  • have a tool the reminds me when I write code that doesn’t confirm to the contracts.
    • With the extra benefit of there being one less thing to think about reviewing a PR

The idea that documenting the type of something is useful goes back before typing was introduced. For example, Sphinx supported rtype before the 1.0 release (over 13 years ago and 5 years before typing was added).


I do think we are at an important time for typing. Having multiple type checkers that don’t always agree is not great. Having mypy still not fully support LiteralSting is not grate. Decisions like the one about TypeGuard are complicated because there is no one clear answer for “is it better to break compatibility because time has shown us that the initial definition isn’t the best instead of 'I know you found TypeGuard first, but what you actually want to use is FooTypeGuard?”.

My current feeling is typing does need to move towards being less fast and loose. I know first hand that there are certain things that python allows, and people wouldn’t consider bad code, which are hard/not possible to express with the current state of typing. But some of these things have complicated edge cases, so it is important to be deliberate about what will and won’t be supported.


  1. Though I haven’t seen anything to say if this is a majority or a vocal minority. ↩︎

  2. because that is what Ubuntu provided ↩︎

4 Likes

I believe Python is still the perfect first programming language, but feel very sympathetic to Skip’s unease. Initially when type hints were first supported I was pretty enthusiastic about them, since in larger projects, or when working with several projects, I found they can make code a lot more readable. So, I don’t dispute their usefulness. (More than that - in large projects, where you also want to rapidly iterate, they are probably already indispensable. If you agree with that, then I think it is not a far stretch to imagine that someone in the not-too-distant future will propose to make them non-optional.)

The actual, gentle (insidious? :slight_smile:) effect that using type-hints has had on me is that it has made me fall in love again with another language – a strongly typed language, where type info is not just something that has meaning during static type-checking but has meaning also at runtime: Rust.
I still love Python - but use it now mainly for fast prototyping.

2 Likes

Yeah, that sounds terrible. The #1 piece of advice in mypy’s documentation on how to type an existing codebase is to a) start small, b) get mypy running before adding annotations: Using mypy with an existing codebase - mypy 1.7.1 documentation. Ideally your would-be contributors would have read this.

The #2 piece of advice in that section is to pin mypy and other dependencies so that everyone runs the exact same analysis everywhere. That said, if you have examples of major behaviour change you think would be instructive that you can link me to, I’d be interested. In the last two years, I introduced GitHub - hauntsaninja/mypy_primer: Run mypy and pyright over millions of lines of code which has helped typeshed and mypy become acutely aware of their disruption budget and has helped eliminate major unintentional behaviour changes.

That said, if a project doesn’t have the bandwidth to review changes or isn’t tolerant to linting, adopting statically checked types is unlikely to be a good fit. I’m glad you ended up in a place that’s comfortable for you and your co-maintainers, thanks for sharing!

7 Likes

Sorry, I should have elaborated on my fence idea. I think we already have a suitable way to document parameters in a function’s docstring. (Something understood by Sphinx? I no longer recall.) My understanding is that Visual Studio no longer uses that info, but relies only on type annotations when prompting for completions.

Maybe I misunderstood what I read. I would like it if someone could explain precisely what’s changed w.r.t. VS. Given the source, it’s likely to be a very popular IDE, so if the VS authors have adopted one way of gathering parameter type information and now ignore the former scheme, users of that older scheme are stuck in two ways as I see it:

  1. The authors need to potentially document their parameter details twice.
  2. Despite perhaps not being interested in type annotations, they are more-or-less forced into it if their code base is to play nice with VS.

Happy to find out I’m way off-base. Even if I am, I worry that popular tools effectively make type annotations non-optional.

1 Like

Personally I find all but the simplest type hints rather verbose, and as a result generally harmful to readability. And of course, you usually don’t want simple type hints, because simple type hints are often over-restrictive (think list[int] when what you actually want is something like Sequence[IntegralButItDoesntNeedToSupportRationalAttributesLikeDenominator]).

And in reality, I’ve never (as far as I’m aware) found an actual bug as a result of adding type hints - which maybe means I’m just lucky (or careful), but does call into question the value of those type hints.

I’d sort of like to be more enthusiastic about type hints, but honestly, the cost/benefit ratio is pretty poor, in my experience.

However, my experience is basically for projects that are either small, have very few maintainers, or both. The trade-offs will be different for larger projects. But that’s not something that gets taken into account - helpful contributors still want to submit PRs adding type annotations, or create issues requesting that I add them. And saying “no” is emotionally draining, because it feels like you have to justify not wanting type annotations, because “obviously” they are a good thing…

One thing that would be useful is if it were easier for projects which do use typing to integrate with libraries that don’t. Maybe that’s typeshed, but I imagine there’s a limit to what projects get added to typeshed. So maybe having a way for project A to define its own stubs for a library it uses would be useful (maybe such a thing already exists?) If that was a more accepted route, maybe the social pressure on everyone to add type annotations would be lower?

10 Likes

Just for context, I think the first version of Python I used was 1.0.2 or similar. My first exposure to Python was around 1995. I came from a C/Pascal background, so I’m not at all unfamiliar with type declarations. Python was a revelation to me in its simplicity.

1 Like

I do very much agree with that. But even those simple hints + mypy have still saved my ass several times. So, this may simply be because you are a better coder than I am :slight_smile:
(It starts getting more bothersome when there are too many # type ignore on lines that are provably correct in all code paths.)

So, hyper-precise, complex long type-hints – I agree, it’s pretty obvious that they hurt readability. And I kind of worry that that is also a direction we’re heading in…

Python itself lives in a competitive world - where people need to get things done in the most efficient way, at scale. The request to do more with typing, to solidify the system, or make it “sounder” seems to me driven by complex, large projects (or multi-faceted projects with several different repos) with many devs - Those projects really need the typing system, as long as they use Python. At some point they may realize that another language may be more suitable. (Think of the inroads that Rust is slowly starting to make in the ML landscape.) So, I wonder if typing will ultimately be the doom of Python as a (widely-used) language or one of the main reasons for its survival. (Not that there is anything wrong with being a little language, of course :slight_smile: )

1 Like

This is surprising to me! I haven’t made many contributions to pip, but one of my recent ones was Use a set for TargetPython.get_tags for performance by hauntsaninja · Pull Request #12204 · pypa/pip · GitHub (makes candidate selection end to end 60% faster). Making sure I changed this data structure everywhere, especially as a newcomer to the codebase, would have been significantly harder without a type checker. And it caught some quite subtle things, like a resulting comparison between a list to a set which is always False.

And saying “no” is emotionally draining, because it feels like you have to justify not wanting type annotations, because “obviously” they are a good thing…

Maybe something constructive is to add an anti-pitch for typing to the typing.readthedocs.io that maintainers can link to?

I imagine there’s a limit to what projects get added to typeshed

Not really :slight_smile: The only limit, like everywhere else, is contributor time. And we have a bunch of testing that lets us review even large contributions with relatively high confidence.
Edit: And you don’t even need to use typeshed, PEP 561 provides a mechanism for anyone to publish stubs for anything for their own use.

7 Likes

Yeah, that sounds terrible. The #1 piece of advice in mypy’s
documentation on how to type an existing codebase is to a) start
small, b) get mypy running before adding annotations:
Using mypy with an existing codebase - mypy 1.7.1 documentation.
Ideally your would-be contributors would have read this.

I think part of the impedance mismatch is that there was only so
much “small work” they could tackle. The project was written by
people who like that Python is loosely/duck-typed, considering it a
reason to choose Python over other more strictly-typed languages,
and took advantage of that overarching feature of the language in
many places, but were willing to accept that perhaps that wasn’t
important and there might be benefits to adopting some clearer
typing. Lots of data structures would have basically just had a type
of “this could be anything” unless a lot of the interfacing code got
rewritten to deal with stricter expectations.

The project relied (and still relies) on clearly-defined models and
validating data against accompanying schemas where strict types were
enforced already with existing solutions. Outside that aspect of the
project, everything was rigorously tested in CI to catch potential
regressions so while refactoring in order to introduce typing was
reasonably safe, the type checker was also not catching any errors
that the testing we already had would have missed.

Since our typing experiment began in 2017 (at least that’s when git
history says we first started running mypy), the guidance around
typing existing codebases may have been lighter or even nonexistent
at that point. I’ll grant that a lot of things have probably changed
with regard to typing in the years since, but the experience of “you
may need to completely rewrite your software if you want useful type
annotations” has left a strong impression on the maintainers, myself
included, who are hesitant to go through that again.

The #2 piece of advice in that section is to pin mypy and other
dependencies so that everyone runs the exact same analysis
everywhere. That said, if you have examples of major behaviour
change you think would be instructive that you can link me to, I’d
be interested. In the last two years, I introduced
GitHub - hauntsaninja/mypy_primer: Run mypy and pyright over millions of lines of code which has helped
typeshed and mypy become acutely aware of their disruption budget
and has helped eliminate major unintentional behaviour changes.

The first occurrence I can find is from late 2018, when something in
mypy 0.650 disagreed with our use of the pyyaml lib. In 2020, we ran
into an issue where mypy required a version of typed-ast that didn’t
work with Python 3.8 so we needed to update, but encountered mypy
issue #1153 related to how we had been redefining imports;
developers were faced with either rewriting parts of the software so
that newer mypy wouldn’t complain, dropping mypy, or not supporting
Python 3.8. Supporting Python 3.9 meant updating mypy again because
it was throwing syntax errors, though we were mostly able to add
skip/ignore for things that version started complaining about. These
are just a few examples I spotted skimming commit messages.

That said, if a project doesn’t have the bandwidth to review
changes or isn’t tolerant to linting, adopting statically checked
types is unlikely to be a good fit. I’m glad you ended up in a
place that’s comfortable for you and your co-maintainers, thanks
for sharing!

Yes, I don’t mean to be negative, I’m sure the typing system is
useful to lots of developers, but in our case it left a bad taste in
lots of mouths and is clearly not a fit for at least some classes of
existing projects. This is why I agree it should remain an entirely
optional part of the language if possible.

3 Likes

As a user of VS Code, the autocompletion and informational pop-ups are often very nice. But they can be utterly terrible when type annotations are complicated. As an example, the popup for divmod says:

(__x: SupportsDivMod[_T_contra@divmod, _T_co@divmod], __y: _T_contra@divmod, /) -> _T_co@divmod

While that information may be easy to get (from type annotations) it’s frankly worse than useless as actual documentation. In contrast, help(divmod) gives:

divmod(x, y, /)
Return the tuple (x//y, x%y). Invariant: div*y + mod == x.

I’m not entirely sure what conclusions to draw from this. But it very much feels like the pressure to “use type annotations” has resulted in a badly degraded user experience. Yes, it may well be harder to use and interpret the help() output. But surely user experience should be key here, not ease of implementation?

I’m not trying to complain about VS Code here, or even moan about unreadable type annotations. What I am trying to say is that the community’s enthusiasm for type annotations (and more specifically, certain types of evangelisation for the feature that goes on) is resulting in tools making bad choices in terms of their actual goals. And that leads to a vicous circle, where we have things like the proposal to add documentation to a parameter’s type, “so that tools can access that documentation”.

I think I agree with this, but for me the “fence” is very much a social one, rather than a technical one. We need to make not having type annotations socially acceptable again, and encourage tools to treat code that chooses not to include annotations as just as valid as annotated code. And we need to accept that type annotations are not necessarily readable or useful to the human reader (see the divmod example above) and promote non-typing solutions that are readable.

That’s a slightly different case. Once you have a fully annotated codebase, with strong trust in the results[1] then I can see that leaning on the type annotations would make maintenance easier. But getting to that point is hard (annotating pip is still a work in progress, and pip doesn’t even have a public API, so we don’t have to worry about things like over-restrictive types in the public API) and it’s not obvious to me that the sort of benefits you suggest will arise, particularly if the project already has a good test suite (pip’s test suite sucks - otherwise I could easily imagine the issues you caught with the type checker being caught by unit tests).

Maybe. But that still requires the project maintainer to make a decision as to whether they want type annotations or not. Whereas my personal position is more along the lines of “I’ll add types when I feel comfortable doing so, and I don’t want people trying to rush me in that decision”.

So that’s the real answer here. Instead of people coming along asking me to annotate my library, why aren’t they using that mechanism? “Write your own stubs” should surely be the natural way of interfacing with an untyped library, not “bug the maintainer to add types”.

I don’t want to come across as over-critical here, as I know type annotations solve a lot of problems for a lot of people, and there’s been a huge amount of work put into them, but it’s discussions like this which leave me with the feeling that things are a huge mess unless you are willing to go full-in and annotate everything. Which is why I’m advocating for a much stronger focus on the “typing is optional” idea, making the experience for people who are hostile, skeptical, or even just cautious[2], towards type annotations less negative.


  1. which comes back to the stability question a little ↩︎

  2. “cautious” is where I feel I stand ↩︎

5 Likes

So that’s the real answer here. Instead of people coming along
asking me to annotate my library, why aren’t they using that
mechanism? “Write your own stubs” should surely be the natural way
of interfacing with an untyped library, not “bug the maintainer to
add types”.

The project I mentioned up-thread basically arrived at that policy.
Resulting complaints are “but then I have to update my stubs every
time the software changes!” Of course, the logical response is “then
why are you asking us to put forth the same effort within the
codebase since you freely admit it’s too much work?”

5 Likes

It is used for some libraries and would be good to recommend more. I maintain tensorflow-stubs libraries. Tensorflow is interested in adding types some day, but hesitant given size library. It does come with it’s own tradeoffs.

If you library A and have A-stubs as a separate library the main question is who are maintainers of each? If maintainers are same people then it’s easy for A to add/change apis and require similar changes to A-stubs. In that case keeping them together and having types in A tends to be less maintenance work for them.

If maintainers are separate people then A-stubs growing independently works fine. Types vs library api becoming inconsistent in new versions still happens, but work to fix lies on maintainers of A-stubs. Typeshed has a tool that tries to update stub libraries to newest version and reports inconsistencies found. Usually number of inconsistencies is low and someone fixes them and releases new stub version compatible with latest.

Other downside is sometimes better types do motivate some refactoring depending on how dynamic library was or weaknesses of typing. Those refactor decisions can only be made by original library A. If cost of refactors is decided to be not worth it, stubs can handle it by being more vague/using Any occasionally.

For my own internal codebases I do write stub packages for other libraries we use that are untyped. I haven’t upstreamed most of them as I’m hesitant to commit to maintaining them. Also some are extremely incomplete and I only wrote small amount of stubs for what we use. Or my internal stubs may be good enough for my team’s usage, but have typing lies/holes that probably need to be improved for typeshed. Tensorflow was one we used most extensively that I decided was worth maintaining open source stubs.

I maintain a bunch of open source libraries and I think there the benefit of type hints to me as a library author has been so-so. There I have to lean on testing a ton.

I’ve also written large closed source Python applications for clients, as part of larger teams. After a certain LOC threshold is passed (say, 10k, although mine were much larger), in that arena type hints stop being optional. The other alternatives at your disposal are either rewrite in a different (statically-typed) language, or be forced into writing so many tests that it effectively destroys velocity and developer experience, again making you rewrite in a different language.

(The funny thing is that nowadays it’s modern to rewrite these systems in Go to get type safety, but I feel the Python type system (even right now) is more expressive and powerful than Go’s. But that’s a different topic.)

These two scenarios also have very different development processes and constraints so it’s not surprising they respond differently to typing or testing.

7 Likes

I’m not the right person to be delivering the message, but I believe in informed decisions, so I went ahead an opened a PR with a proposed anti-pitch. Add an anti-pitch for typing by hauntsaninja · Pull Request #1477 · python/typing · GitHub. I’m hopeful we can all band together and make Skip’s dream of writing the book “Python Type Checking: The Bad Parts” come true :wink:

We’re a little bit off topic from Mike’s initial post (which is a contrary viewpoint to most of the folks in this thread), but I did make sure to make mention of this in the anti-pitch.

Finally, it also seems like a (surprising to me) amount of complaints here are about VSCode behaviour (jump to definition, docstring hover, etc). Has someone tried surfacing this to the VSCode team?

5 Likes

This is a very interesting discussion, it’s useful to see everyone’s perspectives. Personally I’m in the group of people who don’t really use typing because it seems like too much trouble. I do have to read code that uses types, though, so it still winds up affecting me. I also answer Python questions in various chat rooms and forums and in the past few years I notice a trend of more and more questions that boil down to “I have some working code but how can I get the type checks to pass?” This is largely what gives me the perception that people are starting to take on additional labor that is wholly devoted to pleasing the type checker, and I don’t see that as a positive thing.

There’s one thought I keep having as I read through this thread: it seems to me that static typing as applied in Python is going to be fundamentally different from in a language that has had it from an early stage (even if it was optional). A big reason for this is that if the language was designed with static typing, then the language’s runtime type system (hopefully) was designed in tandem with the type checking. This means that things that there will usually be some commonality between things that are hard to specify correctly for type checking and things that are actually hard to do in the language.

But in Python, the type checking is grafted on to the actual types post hoc. There are all sorts of things that people want to do and do do in Python that have developed with nor regard for strict type correctness. This means there are many cases where it’s easy to get the code to work right but harder to get the type checker to realize it is right. And this results in all sorts of awkwardness, such as having parallel nomenclature (dict vs Dict, etc.).

None of that is news to anyone here (and it’s similar to some of what’s said in the typing explanation linked earlier). My gut feeling, though, is that this friction between the runtime type system and the static type system means that there is not going to be a way to please type theory purists without unacceptable levels of disruption to runtime behavior or code readability. We already see the trend in this direction:

I agree entirely, and in my view, things like this should be viewed as red flags telling us to halt and go no further in that direction.

I assume here you mean “harder for the tool/IDE”. But the irony is that it’s much easier to use an interpret the help() output — for a human. And, as you note, that’s precisely the problem. This kind of thing is making programming harder for humans in order to make it easier for IDEs, and I see that as a bad trade. More generally, I’d say there’s a lot of value in keeping Python the language “clean” enough for humans to be able to read and interact with Python code without an IDE being required. And as type annotations become longer and more elaborate, they reduce readability for humans looking directly at the source code (as opposed to hitting some IDE button to give them a summary of the arguments).

I agree with this. I might push it even a bit more: the point of adding features to Python should be to make Python better, not to align with some abstract external system like type theory. So I see arguments that originate as some form of “well, there’s this type theory notion…” as nonstarters.

From the perspective I just mentioned, the question becomes: “Okay, so why do we need anything that you would call a type-checker?” :slight_smile:

I tend to be leery of discussions of “soundness”. In my interactions with type theory fans, my impression has been that they tend to see soundness similarly to how you characterized it, in terms of guarantees. Or, in terms of false positives vs. false negatives, the approach coming from type theory is to minimize false negatives — in the ideal case, to ensure that if the code passes the type checker, a runtime type error is literally impossible.

I don’t think that that is a good road to go down for Python.[1] Like I said above, I see the benefit to users as of immeasurably greater importance than conformance with type theory. So from this perspective, the goal is not to minimize false negatives but to minimize false positives and get some useful level of true positives. That is, I don’t really care how many bugs the type checker doesn’t catch, I just care how many it does help me find, and I definitely care how much it makes me do extra work to get it to find a useful number of bugs.

This may be just another way of saying what you said above: you would consider such things to be just linters, rather than type checkers. Which is fine. But in that case what I’m saying amounts to a hypothesis that there is no possible “real” type checker for Python whose benefits outweigh its costs (e.g., in code readability).

That’s a reasonable position, but I have doubt about whether it’s feasible. The reason is that, as I see it, there is a certain minimum level of “easiness” that is acceptable. If we start from a position of type correctness, and then try to polish things up, even if things get easier and easier, there’s no guarantee they will ever get “easy enough” to justify the effort. And my suspicion is that they won’t.

It’s still possible to take the safety-first approach and work on smoothing out the pain points of a “correct” type system. But I don’t think that is anything that should be presented to the general public as “a good thing to do” until it actually reaches the point where it is easy enough to be a net win (which I don’t think it will).

This is exactly how I feel, and it kind of sums up my point about the friction between Python’s runtime and static type systems. As your example shows, the two systems, although tantalizingly close, always maddeningly remind us of how different they are. But I fear the gulf between the two systems cannot be bridged. The “right” level of annotation for a human reader is something like “list[int]”, but Python’s runtime behavior is too flexible to be adequately characterized by such hints. The result is that you either have to give “incorrect” type hints (which are useful as documentation but not for strict checking), or go the route of the SupportsDivMod example from above. I know which one I’d choose. :slight_smile:

I share that sentiment to some extent. I don’t think I ever used 1.5.2; I can’t remember whether I started with 2.1 or 2.2. There have been many good developments since then. But I do have a sense that there have been diminishing returns with some of the changes over time, and the typing-related changes are perhaps the most prominent example. As a simple metric, by my count there are 24 typing PEPs in the accepted or finished states. I do wonder whether we really needed (or still need) that level of elaboration for an entirely optional language feature with no effect on runtime behavior.


  1. I actually question whether it’s good road for any language, but that’s neither here nor there. ↩︎

6 Likes

I’ve commented about the PR itself on the tracker, but can I just make a general point here?

I want to explicitly state my gratitude to the various typing specialists here who have consistently responded with receptive, positive and helpful comments, towards what must seem like a non-stop barrage of complaints from casual users. Moving discussion to Discourse has a cost, which is a higher percentage of input from people with a limited knowledge of the subject. This can be a real problem, but the quality of responses from the typing community here is incredibly encouraging. Your efforts are appreciated!

21 Likes

Definitely agree with this. I’ve had many unproductive conversations in other venues with type theory advocates, so this discussion has been refreshing and I appreciate it as well. :slight_smile:

2 Likes

I picked up on this based on an earlier comment in this or a related thread. I am not a VSCode user myself. @pf_moore demonstrates how a seemingly simple tooltip can be inscrutable when only the type annotations is used to construct it.

I haven’t read carefully through the proposed anti-pitch (on smartphone, not laptop at the moment), but I like Paul’s notion that the fence I mentioned is a social one, not a technical one. I’m sorry to bad-mouth the VSCode devs, I’m sure they are nice people and quite technically adept, but as that’s the only concrete example I have so far, I will lean into it. Someone on that team must have made the decision that relying on type hints was better than parsing docstrings. Maybe—type hints being syntactic constructs —it reduced code complexity, so was a technical decision at its core. Still, the knock-on effect was a social one, to (subtly) increase pressure on developers to provide type annotations, definitely a social side effect. I’d like to see this social vs technical distribution made in the anti-pitch (if it’s not already there).

Do we have VSCode people in the vicinity who can provide some insight into their rationale?

1 Like