<br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 06:43, Eric V. Smith <span dir="ltr">&lt;<a href="mailto:eric@trueblade.com">eric@trueblade.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On 4/17/2012 5:52 AM, Antoine Pitrou wrote:<br>
&gt; On Mon, 16 Apr 2012 20:41:56 -0400<br>
&gt; Brett Cannon &lt;<a href="mailto:brett@python.org">brett@python.org</a>&gt; wrote:<br>
&gt;&gt; On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou &lt;<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Tue, 17 Apr 2012 01:11:14 +0200<br>
&gt;&gt;&gt; Georg Brandl &lt;<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; No, it&#39;s not just an existing Python, it is (at least currently) the same<br>
&gt;&gt;&gt;&gt; version of Python being built.  Therefore I wrote about the bootstrapping<br>
&gt;&gt;&gt;&gt; problems when bytecode changes.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Depending on Cython is better in that it breaks the bootstrapping cycle,<br>
&gt;&gt;&gt;&gt; but on the other hand the C code may need to be regenerated when the C<br>
&gt;&gt;&gt; API<br>
&gt;&gt;&gt;&gt; changes in an incompatible way.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cython OTOH probably needs Python 2.x, which isn&#39;t that great for<br>
&gt;&gt;&gt; building Python 3. And requiring Cython for developing is not very<br>
&gt;&gt;&gt; contributor-friendly.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Well, required to regenerate _frozen_importlib, but nothing else. I mean<br>
&gt;&gt; making fixes go into importlib directly and get tested that way, not<br>
&gt;&gt; through __import__(). So really Cython would only be needed when<br>
&gt;&gt; importlib._bootstrap has been changed and you are making a commit.<br>
&gt;<br>
&gt; That&#39;s still a large dependency to bring in, while we already have a<br>
&gt; working solution.<br>
&gt; I&#39;d understand using Cython to develop some new extension module which<br>
&gt; requires linking against a C library (and is thus impossible to write<br>
&gt; in pure Python). But for importlib that&#39;s totally non-necessary.<br>
&gt;<br>
&gt; I guess I&#39;m -1 on it.<br>
<br>
</div></div>I agree. If the problem we&#39;re trying to solve is that the generated file<br>
isn&#39;t always rebuilt, bringing in a large dependency like Cython seems<br>
like overkill to me.<br></blockquote><div><br></div><div>Actually Cython would help with a subtle maintenance burden of maintaining *any* C code for import. Right now, Python/import.c:PyImport_ImportModuleLevelObject() is an accelerated C version of importlib.__import__() through checking sys.modules, after which it calls into the Python code. Cython would do away with that C acceleration code (which I have already had to modify once and Antoine found a couple refleaks in).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We basically have a working solution now (thanks, Brett). I think we<br>
should focus on getting it polished. Maybe we can bring in Cython in a<br>
later release, if in the 3.4 timeframe it still seems like we have a<br>
problem to solve. I suspect things will be working fine.</blockquote><div><br></div><div>I don&#39;t view this discussion as work/not work but more of work/work better (possibly; I have severe bias here to cut the C code down to zilch since I don&#39;t want to write anymore of it so I&#39;m definitely not going to make any final call on this topic). </div>

</div>