<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 May 2018 at 05:34, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Sat, 5 May 2018 at 10:41 Eric Fahlgren <<a href="mailto:ericfahlgren@gmail.com" target="_blank">ericfahlgren@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="color:#000000"><span style="color:rgb(34,34,34)">On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi </span><span dir="ltr" style="color:rgb(34,34,34)"><<a href="mailto:a.badger@gmail.com" target="_blank">a.badger@gmail.com</a>></span><span style="color:rgb(34,34,34)"> wrote:</span><br></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><div><div class="gmail_quote"><div dir="ltr">On Fri, May 4, 2018, 7:00 PM Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">What are the obstacles to including "preloaded" objects in regular .pyc files, so that everyone can take advantage of this without rebuilding the interpreter?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><div dir="auto"></div></div></div></blockquote></div></div></span><div dir="auto">Would this make .pyc files arch specific?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div style="color:rgb(0,0,0)">Or have parallel "pyh" (Python "heap") files, that are architecture specific...</div></div></div></div></blockquote><div><br></div></span><div>.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.<br></div></div></div></blockquote><div><br></div><div>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).<br><br></div><div>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.<br clear="all"></div></div><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br><br></div><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>