# Typing adoption open space (Saturday 3-4pm)

## Working on stubs

Danny: A few months ago Meta and Quantsight started an effort to improve stubs in the ecosystem ([post about this](https://discuss.python.org/t/call-for-suggestions-nominate-python-packages-for-typing-improvements/80186/12)).

We've been focusing a lot on pandas and numpy, which are both heavily used libraries that had room for better types. We've been focused on a Pyright measure of completeness and making progress.

An open issue is how to be better at handling multiple systems
- There are github action examples for type checking in micropython
- (Noah) There's also a micropython-stubber library that can help

Another effort has been to make tools we already have, for example some tools from typeshed maintainers, more useful across the ecosystem as a whole. A simple example is just tracking staleness of stubs packages (which often lag by a year or more).

For folks wanting to get involved, some stubs issues are marked as good-first-issues today.

## Side discussion around coordination, planning, where efforts shoudl be placed

(Jukka) How much of this work should also involve type checkers? With lack of standardization on some behaviors, it can be tricky to be sure third-party libraries are interpreted consistently.

(Danny) There's probably work to do here. Overload specification, which just finished, will likely help a lot. Running multiple type checkers against stubs can also help.

(Aaron) Seconding the idea of running multiple type checkers - basically stubs tests run on multiple type checkers.

(Jukka) The importance of stub tests can vary a lot - some check critical things and others exercise rare edge cases.

(Aaron) One thing that's come up is centralization vs federation. Typeshed is the existing centralized place, and we can put lots of tooling in place here. Should we lean into this, trying to centralize more stub efforts in typeshed.

(Glyph) A big challenge for users is that the status of typing features across type checkers is hard to follow.
- Aside: intersections and mapped types are a priority request - both Glyph and colleages have often needed this, especially coming from typescript.

(Carl) Ideally for features at least, `typing` would be the source of truth - decided thing should be in the spec and open issues should be github issues. Maybe we need to do better communicating.

(Glyph) Fair enough; one challenge is a lot of issues wind up on the `typeshed` repo rather than `typing`.

(Steven) Seconding the idea that it's not clear to users, I didn't know there *was* a `typing` repo! It's not as well advertised as it could be.

(Aaron P) It's possible discourse is also a central point of coordination.

## Coordinating

Should we have a place to coordinate discussions around stubs (and `typing` ecosystem work in general)? Discord might be a good idea
- Idea: let's look into getting a dedicated channel on the main python discord. Suggestion is to
- call it `typing-contributors` to be open to lots of folks
- but do try to actively shift non-contributor discussions (e.g. Q&A on how to use types) to the existing `type-hinting` channel

## Back to stubs

There's a lot of open work to do on numpy, for example
- the masked arrays module is in progress, plenty of work to do
- there are lots more issues

Coming back to stubs more generally:
- (Andrew) Is it a goal to eliminate stubs and inline?
- (Aaron) Suppose it were a goal. What is needed to do this?
- A note: Pandas stubs intentionally diverge from the implementation to use more restrictive types we think are more useful in practice, e.g. columns can be anything but we stay `int | str` in the stubs
- (Glyph) There's a middle ground here: we can upstream stub files so that they at least live (and pip download) together
- (Jukka) this seems like a great idea, it helps with staleness
- Note this cuts *against* the benefits of centralizing tools in typeshed, we might need to invest in shared infra that package maintainers can use
- (Carl) an open question we can't easily answer without talking to package maintainers is whether they are happy with having types put into the upstream codebases
- Why do typeshed stubs even exist?
- ... a lot of it is history, at one point types were experimental
- (Jukka) At one point typeshed required folks to try upstreaming first, but there were big downsides to this and we stopped. Upstreaming *is* naturally happening to many projects, but other projects don't want it - especially projects that are used but mostly frozen.
- Some discussion around `py.typed`: configuration to ignore `py.typed` can be important, as can marking `py.typed` as partial.
- One big issue is how to communicate about all this complexity to package maintainers who are often over-stretched and need an easier way to understand how to best use existing tools and features to support users.
- (Glyph) One thing that might help is more metrics tracking the state of typing, with easy to track dashboards and a way to celebrate progress. (Aaron) We did start a little bit of this already with some trackers and a github badge.
- Aaron: To Carl's point that we need to talk to maintainers - it might be worth investing in tooling first; maybe going to maintainers with tooling
- Side discussion: are any existing tools able to type check code and stubs at the same time?
- We don't think any existing checker does this; we probably could retrofit some of them if we really wanted to
- (Jukka) Pretty sure this wouldn't be super useful, it's unusual that untyped code can type check as it is
- That said
- stub-testing ([see here](https://github.com/python/mypy/blob/master/mypy/stubtest.py)) does a more basic check of things like existence and arity and can be very useful
- type testing can also be very useful: put in some examples of simple use cases that *should* type check (note that `assert_type` was added partly to help enable this; also the conformance tests are a special case)
- (Glyph) it would be great to have tooling on top of this so we could record exampels that *shoudn't* type check and verify that we get errors

## Takeaways

Communication: let's move forward with a discord channel and making sure it is advertised (let's also advertise `type-hinting`?).

Let's try putting up an RFC for one or more of the github actions / tools we've discussed here.

Let's make an issue on typeshed to involve them on follow-ups from this discussion.
- Note, if we try to use typeshed to centralize discussions around coverage, it might wind up excluding or being awkward for projects that have already upstreamed types
- This might be a reason to put general discussions elsewhere, e.g. in a repo tracking coverage information.

Idea (Jukka): would it be a good idea to work on ways to include typeshed stubs into pypi packages? This would at least help end users get stubs automatically. (Glyph) I second this, it would probably be a big help to end users, especially if it helps reduce some version collisions (with good release hygiene this at least becomes easier).

Aaron: my goal remains to understand what it would take to get rid of `typeshed/stubs` and get things moved upstream.