Skip to content
This repository was archived by the owner on Aug 25, 2026. It is now read-only.
This repository was archived by the owner on Aug 25, 2026. It is now read-only.

annotations subscripting containers cause TypeErrors #1607

Closed

Description

@vchudnov-g

As per an internal doc, subscripting a container that does not inherit from typing.Generic can cause errors. In particular, a MutableSequence indexed by enums causes an error of the form
TypeError: Parameters to generic types must be types. This can be triggered, for example, by code of the form

        days_of_week: MutableSequence[dayofweek_pb2.DayOfWeek] = proto.RepeatedField(
            proto.ENUM,
            number=2,
            enum=dayofweek_pb2.DayOfWeek,
        )

which we are seeing in the internal part of our publishing pipeline.

Either of these fixes by itself works:

  1. Quoting the type: MutableSequence['dayofweek_pb2.DayOfWeek']
  2. Adding from __future__ import annotations at the top of the file. As per an internal reference, this seems to be related to PEP563, which has a status of Accepted as of 2017, so it's not clear why we would need a fix in the first place.

We should decide and implement the right fix.

Activity

  1. added
    type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
    priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.
    on Feb 22, 2023
  2. atulep commented on Feb 22, 2023

    @atulep
    Contributor

    from future import annotations

    looks reasonable.

  3. self-assigned this
    on Feb 23, 2023
  4. vchudnov-g commented on Feb 23, 2023

    @vchudnov-g
    ContributorAuthor

    Apparently PEP 563 was rolled back from Python3.10: See this Reddit discussion and Python.org discussion, which say that due to compatibility concerns, making PEP563 be the default will not happen until Python3.11.

  5. vchudnov-g commented on Feb 23, 2023

    @vchudnov-g
    ContributorAuthor

    Reading more about "future statements" in the doc, it seems that "All historical features enabled by the future statement are still recognized by Python 3" and are "only kept for backwards compatibility", so presumably this policy will continue to be the case in the future. In that case, the future statement solution seems like a correct and easy fix that won't in itself incur future maintenance.

    (Also if interest: PEP 236 which proposed the __future_ imports.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions