Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Proposal: Support Unpacked `TypeVarTuple` and `tuple` in `Concatenate`

Aberta
  • Algo errado?
#2,332 0 comentários 1 reação 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
python
Domínio
devtools, documentation

Direção de pesquisa

Comece pela seção vinculada da especificação de typing sobre locais de uso válidos e, em seguida, compare a gramática e a semântica propostas com o comportamento de PEP 646 e PEP 612 descrito aqui. O trabalho estará concluído quando uma regra para dividir o prefixo desempacotado de ParamSpec P tiver sido selecionada e documentada, incluindo os casos não ancorado e ilimitado.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

topic: feature

Abstract

PEP 612 introduced ParamSpec and Concatenate to prepend fixed positional parameters to a callable's signature. PEP 646 introduced TypeVarTuple for variadic positional typing in Callable[[*Ts], R]. Because the two PEPs were developed independently, the typing specification does not allow unpacked types (*Ts or *tuple[...]) inside Concatenate.

This proposal extends Concatenate to accept unpack_expressions in its prefix, enabling Callable[Concatenate[*Ts, P], R].

Motivation

Higher-order abstractions like partial application helpers and execution wrappers need to capture an arbitrary number of leading positional arguments while preserving the remaining signature (keyword-only params, defaults, **kwargs) via ParamSpec. Today, this requires repetitive overload ladders:

from typing import Any, Callable, Concatenate, overload

class Wrapper[**P, R]:
    @overload
    def __init__(self, fn: Callable[P, R]) -> None: ...

    @overload
    def __init__[G1](
        self,
        fn: Callable[Concatenate[G1, P], R],
        __g1: G1,
        /,
    ) -> None: ...

    @overload
    def __init__[G1, G2](
        self,
        fn: Callable[Concatenate[G1, G2, P], R],
        __g1: G1,
        __g2: G2,
        /,
    ) -> None: ...

    # Must repeat up to arbitrary maximum arity...
    def __init__(self, fn: Callable[..., R], *args: Any) -> None:
        self._fn = fn
        self._args = args

    def __call__(self, *args: P.args, **kwargs: P.kwargs) -> R:
        return self._fn(*self._args, *args, **kwargs)

With this proposal, the entire ladder collapses to a single generic signature:

from __future__ import annotations
from typing import Callable, Concatenate

class Wrapper[**P, R, *Ts]:
    def __init__(self, fn: Callable[Concatenate[*Ts, P], R], *args: *Ts) -> None:
        self._fn = fn
        self._args = args

    def __call__(self, *args: P.args, **kwargs: P.kwargs) -> R:
        return self._fn(*self._args, *args, **kwargs)

def f(a: str, b: int, *, flag: bool = False, x: float) -> bool: ...

# Ts = () -> P = (a: str, b: int, *, flag: bool = ..., x: float)
w0 = Wrapper(f)
r0 = w0("hello", 42, x=3.14, flag=True)  # type: bool

# Ts = (str,) -> P = (b: int, *, flag: bool = ..., x: float)
w1 = Wrapper(f, "hello")
r1 = w1(42, x=3.14)  # type: bool

# Ts = (str, int) -> P = (*, flag: bool = ..., x: float)
w2 = Wrapper(f, "hello", 42)
r2 = w2(x=3.14)  # type: bool

Specification

Grammar

Update the Concatenate grammar in the typing specification from:

concatenate ::= "Concatenate" "[" type_expression ("," type_expression)* "," parameter_specification_variable "]"

to:

concatenate_prefix_item ::= type_expression | unpack_expression
concatenate ::= "Concatenate" "[" concatenate_prefix_item ("," concatenate_prefix_item)* "," parameter_specification_variable "]"
Semantics

Expansion follows existing PEP 646 semantics: when *Ts is bound to tuple[T1, T2, ..., Tn], Concatenate[*Ts, P] is equivalent to Concatenate[T1, T2, ..., Tn, P]. When *Ts is bound to tuple[()], Concatenate[*Ts, P] simplifies to P. Individual type expressions and unpack expressions may be freely combined in the prefix (e.g. Concatenate[LeadingArg, *Ts, P]).

Open Question: Splitting Boundary

The core design question is: how does a type checker determine the split between the prefix and ParamSpec P?

When the prefix length is statically known, splitting is unambiguous. This covers concrete bounded tuples (Concatenate[*tuple[int, str], P] — always length 2) and value-anchored TypeVarTuples where a companion *args: *Ts pins the length at the call site (the Wrapper example above). These are the primary use cases.

Ambiguity arises when the prefix length is not statically determined:

Case A — Unanchored *Ts (no companion *args: *Ts):

class TaskRunner[**P, R, *Ts]:
    def __init__(self, fn: Callable[Concatenate[*Ts, P], R]) -> None: ...

def compute(user_id: int, query: str, *, timeout: float = 5.0) -> bool: ...

# How many positional params should *Ts capture vs. leave in P?
task = TaskRunner(compute)

Case B — Unbounded tuple (*tuple[T, ...]):

def strip_leading_ints[**P, R](
    fn: Callable[Concatenate[*tuple[int, ...], P], R]
) -> Callable[P, R]: ...

def example(x: int, y: int, z: int, *, flag: bool = False) -> None: ...

# *tuple[int, ...] could match 0, 1, 2, or 3 leading int parameters.
wrapped = strip_leading_ints(example)

Options:

  • Option 1 — Greedy prefix: The prefix consumes all matching positional-capable parameters. In Case A, *Ts = (int, str) and P = (*, timeout: float = 5.0). In Case B, all 3 ints are consumed, leaving P = (*, flag: bool = False).

  • Option 2 — Restrict to fixed-length prefixes initially: Require the prefix length to be statically determined (concrete bounded tuples, companion *args: *Ts, or explicit specialization). Reject unanchored/unbounded prefixes as ambiguous and defer them to a future extension.

Linguagem predominante
Python
Estrelas
1.8k
Forks
302
Merge médio
4h 16min
PRs com merge (30d)
7

Preparar o ambiente

Ainda não verificamos os arquivos de configuração deste projeto. Comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de python/typing

Todas as issues de python/typing

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.