Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[tensor-shapes] Should we allow multiple splats?

Aperta
  • Qualcosa non va?
#4,969 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python, rust
Ambito
compilers

Direzione di ricerca

Start by tracing how type variable tuples, IntTuple shapes, and tuple unpack forms are represented and handled. Compare the existing tuple and IntTuple paths, then determine whether a shared representation can support multiple splats without making them diverge. Done means the design is agreed and multiple splats are supported consistently, with coverage for the examples described in the issue.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs-discussion tensor-shapes

One of the things I noticed when I implemented support for IntTuple[*Elements[S], N] was that the limitation on type var tuple that there can only be one splat is artificial: we define type var tuple in a way where syntactically there can only be one in scope at a time (or at least mostly; I guess you could have one in scope at each of a class and method boundary but that's pretty artificial).

As a result, all the python type checkers I've looked at define unpack forms with only one splat.

But that's a completely artificial limitation, it makes perfect sense to splat arbitrarily many tuples into a new tuple, for example if we allow tuple splats in general then this is sensible:

def f[A: tuple, B: tuple](a: A, x: int, b: B) -> tuple[*Elements[A], int, *Elements[B]]

At the moment I'm not actually trying to support Elements for normal tuple anyway, but the same pattern can happen with IntTuple for shapes (and does happen - for example a sufficiently large cross-product might do this).

To handle this we'd have to change the representation to something like an array of tagged slots that can either be normal types or splatted types.

It is possible to make this change for just IntTuple without changing tuple, which would be less invasive, although the resulting implementation would be less coherent (ideally I don't want the types diverging too much). That's the main blocker: this isn't high enough priority for me to want to change tuple right now, but I also don't want the structures to diverge.

Inspired by a question from @TimothyEDawson in https://github.com/facebook/pyrefly/discussions/4807

Lingua principale
Rust
Stelle
7.2k
Fork
578
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di facebook/pyrefly

Tutte le issue di facebook/pyrefly

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.