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

One-of pattern matching not supported by static type analysis tools

Aperta
#601 7 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
python
Ambito
tooling

Direzione di ricerca

Inizia con la sezione del README sul supporto a one-of e con l'output del compilatore per i campi oneof. Confronta le annotazioni Test generate con gli esempi di pattern matching di pyright, quindi verifica che i campi oneof generati forniscano i type hint previsti senza alterare il comportamento oneof esistente.

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

Descrizione

bug

According to the Readme it should be possible to access fields of a oneof-group by pattern matching so that static analysis tools can provide type hints:

test = Test()
match test:
    case Test(on=value):
        print(value)  # value: bool
    case Test(count=value):
        print(value)  # value: int
    case Test(name=value):
        print(value)  # value: str
    case _:
        print("No value provided")

However, the tool pyright (used by the pylance extension for vscode) does not provide type hints for the second and third case. I first thought this was a bug in pyright, but according to a pyright maintainer this is actually intentional. Apparently, from the point of view of a type checker, the second and third case blocks are unreachable (this pattern even triggers a warning from pyright when configured accordingly).

Possible solution

Let's assume we change the compiler to generate the following class:

@dataclass(eq=False, repr=False)
class Test(betterproto.Message):
    on: Optional[bool] = betterproto.bool_field(1, group="foo")
    count: Optional[int] = betterproto.int32_field(2, group="foo")
    name: Optional[str] = betterproto.string_field(3, group="foo")

Then the following match statement is properly supported by pyright:

test = Test()
match test:
    case Test(on=bool(value)):
        print(value)  # value: bool
    case Test(count=int(value)):
        print(value)  # value: int
    case Test(name=str(value)):
        print(value)  # value: str
    case _:
        print("No value provided")

I think one could argue that it is actually correct to mark these fields optional. What do you think?

System Information

  • python 3.11.9
  • betterproto 2.0.0b7
  • pylance v2024.8.1
Lingua principale
Python
Stelle
1.8k
Fork
235
Metriche di merge delle PR
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 danielgtaylor/python-betterproto

Tutte le issue di danielgtaylor/python-betterproto

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.