<div dir="ltr"><div class="gmail_default" 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 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 class=""><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 class="gmail_default" style="color:rgb(0,0,0)">Or have parallel "pyh" (Python "heap") files, that are architecture specific... (But that would cost more stat calls.)</div></div></div></div>