Re: File based configuration for the import system

--===============6297467447130715574==
Content-Type: multipart/alternative; boundary=001a1139ceda78f270053164ebf3

--001a1139ceda78f270053164ebf3
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 25, 2016 at 7:19 PM, Nick Coghlan <[email protected]> wrote:

>
> This isn't a fully thought out idea, but I figured it was worth posting
> here as a potentially improved motivation for the interpreter bootstrapping
> improvements proposed in PEP 432.
>
> Currently, the proposed motivation there is for a system Python executable
> that has different defaults from the normal CPython runtime:
> https://www.python.org/dev/peps/pep-0432/#a-system-python-executable
>
> It turns out that isn't a particularly compelling motivation for the
> degree of change proposed, since Christian Heimes was able to implement the
> -I switch for isolated mode without too much hassle, and you can fairly
> easily provide a wrapper script that implicitly sets -I for all invocations.
>
> For me though, one of the other motivations behind the proposed changes in
> PEP 432 is getting to replace the current sys.path calculation code in
> getpath.c and getpathp.c with Python code in importlib._bootstrap or
> (depending on boot sequence details) importlib._bootstrap_external.
>

Isn't code that lives in importlib._bootstrap just about as hard to
maintain as code written in C?


> Once we did that, there would be a range of ideas (like allowing
> additional path handling customisations in venv configuration files) that
> become significantly more feasible to implement and maintain.
>
> So, does that sound reasonable to folks as a revised primary motivation
> for that PEP: moving the default sys.path calculation code to Python for
> ease of reuse across implementations, and for ease of maintenance and
> enhancement within CPython itself?
>

Much of the sys.path calculation (everything related to packages) is
already in site.py. And you can skip it with -S.

-- 
--Guido van Rossum (python.org/~guido)

--001a1139ceda78f270053164ebf3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 25, 2016 at 7:19 PM, Nick Coghlan <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><br><div dir=3D"ltr"><div>This=
 isn&#39;t a fully thought out idea, but I figured it was worth posting her=
e as a potentially improved motivation for the interpreter bootstrapping im=
provements proposed in PEP 432.<br><br></div>Currently, the proposed motiva=
tion there is for a system Python executable that has different defaults fr=
om the normal CPython runtime: <a href=3D"https://www.python.org/dev/peps/p=
ep-0432/#a-system-python-executable" target=3D"_blank">https://www.python.o=
rg/dev/peps/pep-0432/#a-system-python-executable</a><br><div><br></div><div=
>It turns out that isn&#39;t a particularly compelling motivation for the d=
egree of change proposed, since Christian Heimes was able to implement the =
-I switch for isolated mode without too much hassle, and you can fairly eas=
ily provide a wrapper script that implicitly sets -I for all invocations.<b=
r><br></div><div>For me though, one of the other motivations behind the pro=
posed changes in PEP 432 is getting to replace the current sys.path calcula=
tion code in getpath.c and getpathp.c with Python code in importlib._bootst=
rap or (depending on boot sequence details) importlib._bootstrap_external.<=
br></div></div></blockquote><div><br></div><div>Isn&#39;t code that lives i=
n importlib._bootstrap just about as hard to maintain as code written in C?=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div></div><div>Once we did that, there would be a range of ideas (like all=
owing additional path handling customisations in venv configuration files) =
that become significantly more feasible to implement and maintain.<br><br><=
/div><div>So, does that sound reasonable to folks as a revised primary moti=
vation for that PEP: moving the default sys.path calculation code to Python=
 for ease of reuse across implementations, and for ease of maintenance and =
enhancement within CPython itself?<br clear=3D"all"></div></div></blockquot=
e><div><br></div><div>Much of the sys.path calculation (everything related =
to packages) is already in site.py. And you can skip it with -S.<br></div><=
/div><br>-- <br><div class=3D"gmail_signature">--Guido van Rossum (<a href=
=3D"http://python.org/~guido" target=3D"_blank">python.org/~guido</a>)</div=
>
</div></div>

--001a1139ceda78f270053164ebf3--

--===============6297467447130715574==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Import-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/import-sig

--===============6297467447130715574==--