This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author carljm
Recipients barry, brett.cannon, carljm, eric.snow, lukasz.langa, ncoghlan, rhettinger
Date 2018-05-16.02:58:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1526439484.66.0.682650639539.issue33499@psf.upfronthosting.co.za>
In-reply-to
Content
Environment variable seems to make a bit more sense for this, since it's not per-invocation; there's no point writing bytecode cache to a particular location unless the next invocation reads the cache from there.

Our use case includes a webserver process that embeds Python; I'm not sure if we could pass a CLI arg to it or not.

Python has lots of precedent for similar environment variables (e.g. `PYTHONHOME`, `PYTHONDONTWRITEBYTECODE`, `PYTHONPATH`, etc). Compared to those, `PYTHONBYTECODEPATH` is pretty much harmless if it "leaks" to an unintended process.

I asked Brett Cannon in the sprints if I should add a CLI flag in addition to the env var; he suggested it wasn't worth it. I'm not opposed to adding the CLI flag, but I think removing the env var option would be a mistake.
History
Date User Action Args
2018-05-16 02:58:04carljmsetrecipients: + carljm, barry, brett.cannon, rhettinger, ncoghlan, lukasz.langa, eric.snow
2018-05-16 02:58:04carljmsetmessageid: <1526439484.66.0.682650639539.issue33499@psf.upfronthosting.co.za>
2018-05-16 02:58:04carljmlinkissue33499 messages
2018-05-16 02:58:04carljmcreate