Usage of Asserts Breaks Code
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- graphql, python
- Ambito
- backend-api-design
Direzione di ricerca
Cerca nel repository i circa 100 usi di assert per la convalida degli argomenti descritti nell’issue, quindi confronta il loro comportamento durante l’esecuzione normale e durante l’esecuzione con Python -O. Esamina ogni punto di chiamata interessato per verificarne il messaggio di errore previsto e conferma che l’esecuzione ottimizzata continui a rifiutare gli input non validi senza modificare la compatibilità esistente con AssertionError.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
This project uses asserts in a lot of places (I found about 100 cases) where they should not be used. They're being used to validate arguments to functions, where the normal Python way would be to use a TypeError or a ValueError. Assertions are essentially debug code, not code for validating arguments.
Any usage of optimize mode or Python (-O or -OO, or PYTHONOPTIMIZE) strips out assertions, making this code useless. That's very problematic if you're generating schema dynamically, as you won't get errors and this library will generate an invalid GraphQL schema.
At this point it's probably too late to change the uses of assert to a proper TypeError or ValueError, without a major version bump as dependent code in other projects may be catching AssertionError.
I'm proposing all instances of assert foo, "Error" be replaced with:
if not foo:
raise AssertionError("Error") # Should be a TypeError
This will at least make the code work in optimize modes where assertions are stripped.
I'll gladly make a PR doing so, but it's hard to tell if this project is still actively developed.
- Lingua principale
- Python
- Stelle
- 371
- Fork
- 174
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di graphql-python/graphql-core-legacy
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Quiver sourceAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
graphql-python/graphql-core-legacy#286 · 3 reazioni ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
graphql-python/graphql-core-legacy#280 · 2 commenti · 1 reazione ·
-
Add support for custom validators in default GraphQL backendForse già presa @JoaRiski l’ha presa 2422 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Tutte le issue di graphql-python/graphql-core-legacy
Issue simili
-
Atomic append fails to create a missing fileForse già presa @harbinresearcher l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
fabiocaccamo/python-fsutil#201 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
task
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
danparshall/claude_researcher#87 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
GhostManager/Ghostwriter#998 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
datajoint/datajoint-python#1586 ·
I maintainer di solito rispondono entro 1 giorno