On Tue, Apr 17, 2012 at 06:43, Eric V. Smith <e...@trueblade.com> wrote:
> On 4/17/2012 5:52 AM, Antoine Pitrou wrote: > > On Mon, 16 Apr 2012 20:41:56 -0400 > > Brett Cannon <br...@python.org> wrote: > >> On Mon, Apr 16, 2012 at 20:27, Antoine Pitrou <solip...@pitrou.net> > wrote: > >> > >>> On Tue, 17 Apr 2012 01:11:14 +0200 > >>> Georg Brandl <g.bra...@gmx.net> wrote: > >>>> > >>>> No, it's not just an existing Python, it is (at least currently) the > same > >>>> version of Python being built. Therefore I wrote about the > bootstrapping > >>>> problems when bytecode changes. > >>>> > >>>> Depending on Cython is better in that it breaks the bootstrapping > cycle, > >>>> but on the other hand the C code may need to be regenerated when the C > >>> API > >>>> changes in an incompatible way. > >>> > >>> Cython OTOH probably needs Python 2.x, which isn't that great for > >>> building Python 3. And requiring Cython for developing is not very > >>> contributor-friendly. > >>> > >> > >> Well, required to regenerate _frozen_importlib, but nothing else. I mean > >> making fixes go into importlib directly and get tested that way, not > >> through __import__(). So really Cython would only be needed when > >> importlib._bootstrap has been changed and you are making a commit. > > > > That's still a large dependency to bring in, while we already have a > > working solution. > > I'd understand using Cython to develop some new extension module which > > requires linking against a C library (and is thus impossible to write > > in pure Python). But for importlib that's totally non-necessary. > > > > I guess I'm -1 on it. > > I agree. If the problem we're trying to solve is that the generated file > isn't always rebuilt, bringing in a large dependency like Cython seems > like overkill to me. > 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). > > We basically have a working solution now (thanks, Brett). I think we > should focus on getting it polished. Maybe we can bring in Cython in a > later release, if in the 3.4 timeframe it still seems like we have a > problem to solve. I suspect things will be working fine. I don'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't want to write anymore of it so I'm definitely not going to make any final call on this topic).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
