From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9430C3601E for ; Thu, 10 Apr 2025 13:05:30 +0000 (UTC) Subject: Re: python3: Allow to specify which pyc files to keep To: openembedded-core@lists.openembedded.org From: "Lukas Woodtli" X-Originating-Location: Zurich, CH (185.132.16.78) X-Originating-Platform: Linux Firefox 136 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 10 Apr 2025 06:05:21 -0700 References: In-Reply-To: Message-ID: <31851.1744290321098835072@lists.openembedded.org> Content-Type: multipart/alternative; boundary="ktMlFJEGRiN9UaVnrEYt" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 10 Apr 2025 13:05:30 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/214665 --ktMlFJEGRiN9UaVnrEYt Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 >=20 >=20 >> The key question is whether this level of configuration is generally >> useful enough to be worth us maintaining it in OE-Core. I don't know if >> this is something you needed for a one off investigation or that people >> need it in general. >=20 > I think it would be good to step back and look at what these > optimization levels actually do. Upstream clearly treats them as > optional opt-in via python interpreter command line switch or > environment variable, which means they don't think picking a higher > default level is something python users should be doing. So why would > we be going against this approach? >=20 >=20 The reason to use these features of the Python interpreter is that we devel= op for resource restricted devices. The target device should not need to compile t= he Python files to byte-code at runtime (which happens regardless of the optimization= level). We can do this work at build time. Moreover, Embedded devices usually have restricted storage size. So using the optimization level 2 for pyc fil= es is sensible. Most embedded devices don't need the docstrings in the Python files (simmil= ar to not needing the man pages). So we can get rid of them (that is what optimiz= ation level 2 does, apart from disabling asserts). Lukas --ktMlFJEGRiN9UaVnrEYt Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The key question is whether this level of configuration is gene= rally
useful enough to be worth us maintaining it in OE-Core. I don't = know if
this is something you needed for a one off investigation or th= at people
need it in general.
I think it would be good to step back and look at what these
optimizat= ion levels actually do. Upstream clearly treats them as
optional opt-i= n via python interpreter command line switch or
environment variable, = which means they don't think picking a higher
default level is somethi= ng python users should be doing. So why would
we be going against this= approach?
 
 
The reason to use these features of the Python interpreter is that we = develop for
resource restricted devices. The target device should not need to comp= ile the Python
files to byte-code at runtime (which happens regardless of the optimiz= ation level).
We can do this work at build time. Moreover, Embedded devices usually<= /div>
have restricted storage size. So using the optimization level 2 for py= c files is sensible.
Most embedded devices don't need the docstrings in the Python files (s= immilar to
not needing the man pages). So we can get rid of them (that is what op= timization
level 2 does, apart from disabling asserts).
 
Lukas
 
--ktMlFJEGRiN9UaVnrEYt--