On 6 May 2018 at 05:34, Brett Cannon email@example.com wrote:
On Sat, 5 May 2018 at 10:41 Eric Fahlgren firstname.lastname@example.org wrote:
On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi email@example.com wrote:
On Fri, May 4, 2018, 7:00 PM Nathaniel Smith firstname.lastname@example.org wrote:
What are the obstacles to including "preloaded" objects in regular .pyc files, so that everyone can take advantage of this without rebuilding the interpreter?
Would this make .pyc files arch specific?
Or have parallel "pyh" (Python "heap") files, that are architecture specific...
.pyc files have tags to specify details about them (e.g. were they compiled with -OO), so this isn't an "all or nothing" option, nor does it require a different file extension. There just needs to be an appropriate finder that knows how to recognize a .pyc file with the appropriate tag that can be used, and then a loader that knows how to read that .pyc.
Right, this is the kind of change I had in mind (perhaps in combination with Diana Clarke's suggestion from several months back to make pyc tagging more feature-flag centric, rather than the current focus on a numeric optimisation level).
We also wouldn't ever generate this hypothetical format implicitly - similar to the new deterministic pyc's in 3.7, they'd be something you had to explicitly request via a compileall invocation. In the Linux distro use case then, the relevant distro packaging helper scripts and macros could generate traditional cross-platform pyc files for no-arch packages, but automatically switch to the load-time optimised arch-specific format if the package was already arch-specific.