Add `limit=` keyword to `int()` and `str()` functions to avoid contention on global `PYTHONINTMAXSTRDIGITS`
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 18/100
Piste de recherche
Commencez par la proposition liée sur discuss.python.org et la discussion qu’elle référence, puis examinez comment CPython applique actuellement PYTHONINTMAXSTRDIGITS aux conversions int() et str(). L’issue ne nomme aucun fichier source ni aucun test ; le comportement de l’API, le périmètre de l’implémentation et la couverture devraient donc être définis d’un commun accord avant de commencer le travail.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Enhancement
With the mitigations for CVE-2020-10735 in place, there's tension between:
- security-minded folks which need to protect against DoS attacks
- scientific (and other) use-cases which need to process large numbers in some form
Those are both vying for the one setting (PYTHONINTMAXSTRDIGITS) that controls this, which is unfortunately global state.
Since several such libraries are often loaded in the same runtime, this makes it very tricky to balance.
The idea is simply to add a limit=None keyword to int() and str(), which defaults to PYTHONINTMAXSTRDIGITS if None, but can be set to any other value. Setting it to 0 (for example, or -1) would make it unlimited.
Pitch
This would not solve all the fallout right away, but it would provide a sane path forward, where the default can be safe, and callsites can explicitly opt into saying "I want this call to have a different limit".
In particular, it would not require global state to balance the divergent needs of different parts of the ecosystem anymore.
In case a spectacular new conversion algorithm comes along, the default could eventually be set to infinite again, but the API wouldn't stand out as useless/harmful, but still serve a clear purpose, and so this proposal is independent of future string algorithms or default limits.
Previous discussion
https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889/
and many more places linked from there
- Langage dominant
- Python
- Étoiles
- 77.2k
- Forks
- 36k
- Merge moyen
- 1 j 9 h
- PR mergées (30 j)
- 558
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de python/cpython
-
docs pending
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
stdlib type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
-
stdlib type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
-
build type-bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
-
stdlib topic-email type-feature
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
Toutes les issues de python/cpython
Issues similaires
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
zostera/django-bootstrap4#894 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
use-agent-os/agent-os#3276 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
zephyrproject-rtos/zephyr#119726 ·
-
area/auth bug comp/agent P3 platform/discord type/security
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
NousResearch/hermes-agent#117848 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
zilliztech/memsearch#759 ·