theskumar / theskumar/python-dotenv
Proposal: optional native parser backend with pure-Python fallback
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Python
- Sterne
- 8.9k
- Forks
- 581
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
python-dotenv optional native parser backend
Problem
python-dotenv parsing is on the configuration path of real consumers such as
pydantic-settings. We measured complete consumer calls, not parser-only
throughput, on the same macOS arm64 / CPython 3.14 environment.
Proposal
- Keep the current pure-Python parser and
pip install python-dotenvdefault. - Add an optional
nativeextra whose backend-only dependency is
fast-dotenv-rs-backend. - Keep the Rust package separate from the
dotenvnamespace and console
script; the adapter only converts lossless parser records into the existing
BindingandOriginalobjects. - If the extra/backend is absent, the existing pure-Python path remains in
use. If an explicitly selected backend violates its versioned contract or
raises, surface that failure rather than silently masking it.
Runtime evidence
- Upstream base:
a00cb2eed0704cd6d2071b2004c37e95ccc86ee5. - Backend implementation:
fast-dotenv-rscommits
7cbdca0and95ea5c1in the Master integration clone; shared Rust core
and backend-only wheel are ready for review. - Upstream adapter patch:
python-dotenvcommits
0c1d17b9878ae2b390616fbd8b64f605f9fd9d67and
f5856435e229485040e0e11530a191b0f51007df. - Exact Binding differential: 1,088 records, including 500 generated valid
and 500 generated malformed records; native OFF, native ON, and backend
direct paths each retained 0 mismatches. - Upstream suite:
264 passed, 1 skippedin both OFF and ON runs, using a
portable fixture for the host-specificprintenv --versiontest. - Native call proof:
fast_dotenv_rs_backend.parse_bindingswas observed on
the sameparse_streampath; backend and official package coexist without
a top-leveldotenvcollision. - Real consumer benchmark:
dotenv_values,load_dotenv,
pydantic-settingsservice/worker settings, repeated loads, and cold
startup across small/medium/large fixtures. Semantic hashes matched;
30 p50 metrics classified as21 win / 8 neutral / 1 lossunder a 2%
neutral band. The only loss was small cold CLI startup (-1.6675 ms);
representative warm savings were0.1266 msfor smalldotenv_values,
0.7477 msfor medium, and4.9392 msfor large.
Maintainer questions
- Is an optional backend extra acceptable, with backend wheels maintained
outside the defaultpython-dotenvrelease path? - Should activation use the
nativeextra, another name, or a different
boundary? - Which platform, PyPy/free-threaded, supply-chain, and rollback guarantees
are required before merge?
This is a concrete proposal with a merge-ready local patch. The backend is not
yet published to PyPI, and the current wheel evidence is macOS arm64 only;
those are intentionally open release gates, not hidden claims.
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne mit dem bestehenden parse_stream-Pfad und untersuche, wie Parserdatensätze in Objekte vom Typ Binding und Original umgewandelt werden; sieh dir anschließend die zitierten Adapter-Commits und den Einstiegspunkt fast_dotenv_rs_backend.parse_bindings an. Führe die Upstream-Test-Suite in den Modi native OFF und ON aus und vergleiche die differentiellen Ergebnisse. Als erledigt gilt die Aufgabe erst, wenn die Maintainer-Entscheidungen zu extra, Plattform- und Interpreter-Unterstützung, Supply-Chain-Garantien und Rollback vor dem Release vorliegen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- python, rust
- Bereich
- backend
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Aktiv
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 28/100