# PEP 829: Structured Startup Configuration Files **URL:** \ **Category:** PEPs\ **Created:** [April 1, 2026, 9:57pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789 "2026-04-01T21:57:54Z")\ **Posts on this page:** 12\ **Page:** 6
**Author:** ![emmatyping](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/emmatyping/32/36516_2.png) [@emmatyping](https://discuss.python.org/u/emmatyping)\ **Post date:** [April 17, 2026, 2:38am UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/101 "2026-04-17T02:38:26Z")
I really love the newest revision of the PEP! Thank you Barry for proposing this and I hope the SC approves it. I have one minor suggestion which is to specify that the `.start` file should be `utf-8` encoded to simplify parsing. Optionally, this could be `utf-8-sig` to allow for BOMs, since pth files allow them, but I think `.start` files should _not_ fallback to the current locale like pth files do. Digging through git history and discussions, it looks like the locale fallback was added because [setuptools was writing locale-encoded pth files already](https://github.com/python/cpython/issues/77102#issuecomment-2051033553). With a new format we can ensure the file must be UTF-8 and make everyone’s lives easier. ---
**Author:** ![hauntsaninja](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hauntsaninja/32/12451_2.png) [@hauntsaninja](https://discuss.python.org/u/hauntsaninja)\ **Post date:** [April 17, 2026, 4:01am UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/102 "2026-04-17T04:01:00Z")
Some of these have been mentioned already, but since it’s up for pronouncement: - I don’t understand the motivation for silent error handling. I haven’t ever seen any complaints about pth’s normal error handling (and authors can always try-except if fallibility is okay) - The deprecation period seems a little short - I’m a little skeptical of the security benefits. I would find it useful to see spelled out what makes PEP 829 more constrained and auditable - The PEP says stuff that could maybe unintentionally mislead readers with less context, e.g. “The overall attack surface is not eliminated — a malicious package can still cause arbitrary code execution via entry points”. There are many other ways a malicious package could cause arbitrary code execution. I think the PEP should mention that somewhere in order to avoid giving some future reader the impression that .pth / .start is the only hole ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [April 17, 2026, 9:36am UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/103 "2026-04-17T09:36:27Z")
> [@emmatyping](#): > > Digging through git history and discussions, it looks like the locale fallback was added because [setuptools was writing locale-encoded pth files already](https://github.com/python/cpython/issues/77102#issuecomment-2051033553). It’s because we were parsing with the current locale, and had to migrate to UTF-8 in a way that wouldn’t break compatibility. setuptools was writing it because we were reading it. ---
**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\ **Post date:** [April 17, 2026, 1:19pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/104 "2026-04-17T13:19:22Z")
> [@hauntsaninja](#): > > I’m a little skeptical of the security benefits. I would find it useful to see spelled out what makes PEP 829 more constrained and auditable Aside from explainability, the two main concrete benefits are: - the presence of startup code is visible in a wheel’s file listing (right now, pth files _might_ indicate startup code, while in the future, they will necessarily be passive, while start files will be active) - the entry point import events will arguably be easier to identify in the existing audit hook mechanism than the code compilation hooks that currently fire Is it a massive improvement? No, but that’s also not the claim. ---
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [April 17, 2026, 1:38pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/105 "2026-04-17T13:38:23Z")
neither of those are security benefits though. Both are beneficial to auditability. For an issue that has gotten as much visibility as this due to a specific abused case in the wild, and that some knee jerk reactions were wanting the functionality dead entirely, why is that distinction still being lost in presenting it? It’s important that people get accurate information about what is actually improving and that people don’t get the wrong impression that this somehow makes their existing choice to install a package any more or less secure. ---
**Author:** ![bwoodsend](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bwoodsend/32/4027_2.png) [@bwoodsend](https://discuss.python.org/u/bwoodsend)\ **Post date:** [April 17, 2026, 2:02pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/106 "2026-04-17T14:02:16Z")
Is it even possible to have a `.pth` file in a wheel that isn’t the code execution type and still makes sense? Sticking an absolute path in a wheel is very unlikely to be portable and relative paths within `site-packages` sound even less useful. So for all intents an purposes, couldn’t a `.pth` in a wheel already be assumed to be the _run code on startup_ type? ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [April 17, 2026, 6:30pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/107 "2026-04-17T18:30:18Z")
> [@emmatyping](#): > > I have one minor suggestion which is to specify that the `.start` file should be `utf-8` encoded to simplify parsing. Optionally, this could be `utf-8-sig` to allow for BOMs, since pth files allow them, but I think `.start` files should _not_ fallback to the current locale like pth files do. I agree that `.start` files should be `utf-8` or probably `utf-8-sig`. It’s a little tricky in my [reference implementation](https://github.com/warsaw/cpython/blob/pth2toml/Lib/site.py#L155) because I’ve refactored the code so that both the `.pth` and `.start` files are read using the same logic. So I wonder if we should also deprecate the fallback to current locale for `.pth` files too? I guess it wouldn’t be that ugly to switch on the `suffix` to decide whether to fallback or not. Philosophically, I’d like for both files to use the same rules and don’t want to gate the semantics on the implementation. ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [April 17, 2026, 6:34pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/108 "2026-04-17T18:34:16Z")
> [@bwoodsend](#): > > Sticking an absolute path in a wheel is very unlikely to be portable and relative paths within `site-packages` sound even less useful. You’re assuming usage in publicly released libraries though. Both path extension mechanisms could be useful in non-public code where the execution environment is more tightly constrained. ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [April 17, 2026, 6:37pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/109 "2026-04-17T18:37:07Z")
I agree with both points @ncoghlan, and thanks for clearly expressing it. I think people are getting hung up on claims that the PEP isn’t making, but I take that as my responsibility to clarify the PEP. I might just lift these bullet points (with Acknowledgement of course!). ---
**Author:** ![emmatyping](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/emmatyping/32/36516_2.png) [@emmatyping](https://discuss.python.org/u/emmatyping)\ **Post date:** [April 17, 2026, 6:41pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/110 "2026-04-17T18:41:28Z")
> [@barry](#): > > So I wonder if we should also deprecate the fallback to current locale for `.pth` files too? Agreed, it makes sense to deprecate this now as well IMO. > [@barry](#): > > I guess it wouldn’t be that ugly to switch on the `suffix` to decide whether to fallback or not. Up to you, but I think we should not make our lives harder in the future by allowing locale-specific `.start` files. ---
**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\ **Post date:** [April 17, 2026, 6:48pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/111 "2026-04-17T18:48:49Z")
> [@hauntsaninja](#): > > I don’t understand the motivation for silent error handling. Generally speaking, we want to avoid annoying end users with errors that they can’t do anything about\[1\]. I would hope that most developers would catch any problems during testing, long before the code gets into end users hands. > [@hauntsaninja](#): > > The deprecation period seems a little short I think a three year deprecation period for the `.pth` code execution functionality is a good compromise. We really want to get these out of the ecosystem, and with @ncoghlan 's excellent suggestion about an easy migration path and straddling approach, I totally think it’s doable. We’ll add another two years for silently ignoring `import` lines in `.pth` files so users of straddling code won’t get overwhelmed with inactionable error messages while Python versions that both support and don’t support 829 are active. * * * 1. except perhaps report a bug, which can be … unsatisfying ---
**Author:** ![savannahostrowski](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/savannahostrowski/32/25496_2.png) [@savannahostrowski](https://discuss.python.org/u/savannahostrowski)\ **Post date:** [April 24, 2026, 11:58pm UTC](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789/112 "2026-04-24T23:58:44Z")
The SC has discussed and is pleased to accept [PEP 829 - Package Startup Configuration Files](https://peps.python.org/pep-0829/)! The SC is comfortable with the three-year deprecation window as proposed. However, we request the following revisions to the text before the PEP lands: - The current abstract buries the lede a bit. The first paragraph should highlight what is materially changing: `.start` files with `pkg.mod:callable` syntax, a three-year `.pth` import-line deprecation, and retained path-extension `.pth`. - The security implications should be more specific. The PEP narrows one specific vector: supply-chain attacks via `exec()` of `.pth` import lines. The changes do not materially alter the broader threat model. We recommend explicitly acknowledging that the overall “malicious installed package runs code at startup" threat is unchanged. The concrete win is that the code a package intends to run becomes inspectable as a declarative entry point rather than an opaque string passed to `exec()`. The SC views PEP 829 as a sensible improvement to the interpreter layer, compatible with and not precluding future work in the installer and packaging standards space. We encourage contributors interested in that broader direction to consider proposing complementary standards. Accepting PEP 829 is not a statement that the interpreter layer is the end of this work. Thank you for your work on this, Barry, and congratulations! _ **Edit** : …and just for the record, as PEP author, Barry had no part in this decision!_ [Previous page](https://discuss.python.org/t/pep-829-structured-startup-configuration-files/106789.md?page=5)