Repository navigation
Prefer to split Python 2 and 3 stubs #5049
Description
Currently, CONTRIBUTING says:
It is preferred to use a single stub for every module. ...
I would suggest that we actually recommend the opposite and work towards splitting the remaining stubs. In my experience we only get very occasional PRs for Python 2, which indicates to me that they are in a mostly acceptable state for users relying on them.
Splitting them has a few advantages:
- Simpler and clearer stubs overall, less Python 2 cruft (e.g.
Text) in Python 3 stubs - Easier evolution and maintenance of Python 3 stubs
- Less risk of breaking Python 2 stubs when making changes for Python 3
- Eventually slightly simpler type checker code, since we can get rid of the
python2/python3metadata fields
The only disadvantage I can think of is that changes for Python 3 don't get automatically propagated to Python 2 and vice versa. But considering the stable nature of Python 2 code I am not sure how relevant that is in practice.
Activity
hauntsaninja commentedon Feb 22, 2021
I agree, ship it.
srittau commentedon Feb 22, 2021
Also cc @JukkaL and @ilevkivskyi as the ones implementing the current structure.
ilevkivskyi commentedon Feb 22, 2021
This should be good for mature stubs, but for new stubs with few and/or imprecise types this may cause some duplication of work. Anyway, not a strong preference for me.
JukkaL commentedon Feb 23, 2021
This sounds reasonable. The fraction of Python 2 users will gradually decline, so requiring contributors to make sure their changes work for Python 2 is going to be a big ask. By preserving the existing Python 2 stubs, we will still be able to provide a pretty good (and perhaps more importantly, stable!) experience for Python 2 users, while making it easier to improve Python 3 stubs.
For new stubs, I think that we should only recommend creating Python 3 versions by default, unless the contributor explicitly wants to support Python 2. Currently the contributor guidelines suggest that stubs should support Python 2 if the target package supports Python 2. Since Python 2 has reached end of life, we can perhaps relax this.
Suggest splitting Python 2 stubs
Suggest splitting Python 2 stubs (#5189)