RetroSearch Browse

Sat May 5 12:16:24 EDT 2018 · https://mail.python.org/pipermail/python-dev/2018-May/153415.html

On 5 May 2018 at 11:58, Nathaniel Smith <njs at pobox.com> 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?
>
> Off the top of my head:
>
> We'd be making the in-memory layout of those objects part of the .pyc
> format, so we couldn't change that within a minor release. I suspect this
> wouldn't be a big change though, since we already commit to ABI
> compatibility for C extensions within a minor release? In principle there
> are some cases where this would be different (e.g. adding new fields at the
> end of an object is generally ABI compatible), but this might not be an
> issue for the types of objects we're talking about.
>

I'd frame this one a bit differently: what if we had a platform-specific
variant of the pyc format that was essentially a frozen module packaged as
an extension module? We probably couldn't quite do that for arbitrary
Python modules *today* (due to the remaining capability differences between
regular modules and extension modules), but multi-phase initialisation gets
things *much* closer to parity, and running embedded bytecode instead of
accessing the C API directly should avoid the limitations that exist for
classes defined in C.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180506/e5412bb4/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-May/153415.html below:

[Python-Dev] A fast startup patch (was: Python startup time)