"Martin v. Löwis", 16.04.2012 16:07: >> We have other instances of this (e.g. the Objects/typeslots.inc file >> is generated and checked in), but in the case of importlib, we have >> to use the ./python binary for freezing to avoid bytecode >> incompatibilities, which obviously is a problem if ./python isn't >> built yet. > > As for dependencies on byte code: we could consider using Cython instead > of freeze (not sure whether Cython would build the bootstrap correctly; > it may need to be fixed first).
I assume that this would be needed rather early during the interpreter startup, so you're right that there may be obstacles due to expectations in the generated C code that may not be there yet. But I think it's worth a try. Cython is rather predictable in its requirements given the Python source code. Just run the module through Cython and see what it gives you. (Note that you may need the latest github master version to make everything work nicely in Py3.3, I keep adapting things there as I find them - our CI server runs daily tests against the latest CPython master.) One thing Cython does during module initialisation is to import the builtins module using PyModule_AddModule(). Does that work already at this point? It uses it mostly to cache builtins that the module uses. That can be disabled, though, and I also wouldn't mind letting Cython put a preprocessor guard into that code that would let it do something else based on a macro that CPython defines at this point, maybe even just Py_BUILD_CORE. We already do these things for all sorts of purposes. And, obviously, the module init function can also be called directly instead of running it as part of an import. That's commonly done when using Cython modules in an embedded Python runtime. > With that, we would get semi-readable > source code, which should also play more nicely with hg diffs. There's still a Cython patch hanging around on github that aims to keep the C code from changing all that drastically on Python source code changes (e.g. due to source line references etc.). Might be worth integrating for something like this. There's also a switch that disables the (helpful) reproduction of the Python code context in C code comments, in case that gets in the way for diffs. > On the down side, we would depend on Cython for evolving . Right, although not as a strict dependency. The code would still work just fine in plain Python. But it would depend on Cython for performance. And we usually recommend to ship the generated C sources anyway to avoid a user dependency on Cython, so this use case is quite normal. Stefan _______________________________________________ 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
