Message316758
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. |
|
Date |
User |
Action |
Args |
2018-05-16 02:58:04 | carljm | set | recipients:
+ carljm, barry, brett.cannon, rhettinger, ncoghlan, lukasz.langa, eric.snow |
2018-05-16 02:58:04 | carljm | set | messageid: <1526439484.66.0.682650639539.issue33499@psf.upfronthosting.co.za> |
2018-05-16 02:58:04 | carljm | link | issue33499 messages |
2018-05-16 02:58:04 | carljm | create | |
|