python / python/mypy

Inconsistent behavior w.r.t missing builtins

Open
#14,547 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug topic-developer topic-tests
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

Issue

Some of the builtins fixtures are sparse to the point that they're missing even the declaration of dict, list, tuple etc. types. The austerity is justified by improved tests performance, and it's understood that specific tests can specify a broader fixture without slowing down other tests.

However, some core features rely on the presence of those types, e.g.

  • functions' **kwargs
  • modules' __annotations__
  • namedtuple's attributes like _field_types

I've observed 3 different strategies used to handle the types absence:

I think we should recommend and, ideally, consolidate on one strategy.

Motivation

Case in point: Recently while implementing #14526, I had to "play" a whack-a-mole with unrelated tests breaking. I've used **kw which required me to add dict to a number of builtins fixtures, which in turn caused __annotations__ to materialize where they didn't before, and failed some other tests.

I think ideally we shouldn't have this whack-a-mole, and tests should be less brittle.

Recommendation

Which strategy to adopt? While it's good practice to structure code to be more testable, I think it's normally discouraged to have code paths that are only due to testing. Since those builtins should universally exist in "production", I think crash should be our strategy.

Since code typically relies only on the presence of those classes (not their methods), we can put in place a rule (validated by tests) that any builtins fixture must define a baseline of types, even if empty. This shouldn't affect performance greatly, and provide a comfortable baseline.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing the missing-builtins handling in mypy/types.py, mypy/semanal.py, and mypy/semanal_namedtuple.py, along with the affected builtins fixtures and tests. Determine a consistent strategy for required builtin declarations and update the relevant tests so fixture behavior is stable across **kwargs, annotations, and NamedTuple handling.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.