Skip to content

Prefer to split Python 2 and 3 stubs #5049

@srittau

Description

@srittau

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/python3 metadata 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    project: policyOrganization of the typeshed project

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions