Hey Barry, On Thu, Jan 21, 2010 at 3:34 AM, Barry Warsaw <ba...@python.org> wrote: > On Jan 20, 2010, at 11:05 PM, Jack Diederich wrote: > >>Does disabling the LLVM change binary compatibility between modules >>targeted at the same version? At tonight's Boston PIG we had some >>binary package maintainers but most people (including myself) only >>cared about source compatibility. I assume linux distros care about >>binary compatibility _a lot_. > > A few questions come to mind: > > 1. What are the implications for PEP 384 (Stable ABI) if U-S is added?
PEP 384 looks to be incomplete at this writing, but reading the section "Structures", it says """ Only the following structures and structure fields are accessible to applications: - PyObject (ob_refcnt, ob_type) - PyVarObject (ob_base, ob_size) - Py_buffer (buf, obj, len, itemsize, readonly, ndim, shape, strides, suboffsets, smalltable, internal) - PyMethodDef (ml_name, ml_meth, ml_flags, ml_doc) - PyMemberDef (name, type, offset, flags, doc) - PyGetSetDef (name, get, set, doc, closure) """ Of these, the only one we have changed is PyMethodDef, and then to add two fields to the end of the structure. We have changed other types (dicts and code come to mind), but I believe we have only appended fields and not deleted or reordered existing fields. I don't believe that introducing the Unladen Swallow JIT will make maintaining a stable ABI per PEP 384 more difficult. We've been careful about not exporting any C++ symbols via PyAPI_FUNC(), so I don't believe that will be an issue either, but Jeffrey can comment more deeply on this issue. If PEP 384 is accepted, I'd like it to include a testing strategy so that we can be sure that we haven't accidentally broken ABI compatibility. That testing should ideally be automated. > 2. What effect does requiring C++ have on the embedded applications across the > set of platforms that Python is currently compatible on? In a previous > life I had to integrate a C++ library with Python as an embedded language > and had lots of problems on some OSes (IIRC Solaris and Windows) getting > all the necessary components to link properly. To be clear, you're talking about embedding Python in a C/C++ application/library? We have successfully integrated Unladen Swallow into a large C++ application that uses Python as an embedded scripting language. There were no special issues or restrictions that I had to overcome to do this. If you have any applications/libraries in particular that you'd like me to test, I'd be happy to do that. > 3. Will the U-S bits come with a roadmap to the code? It seems like this is > dropping a big black box of code on the Python developers, and I would want > to reduce the learning curve as much as possible. Yes; there is http://code.google.com/p/unladen-swallow/source/browse/trunk/Python/llvm_notes.txt, which goes into developer-level detail about various optimizations and subsystems. We have other documentation in the Unladen Swallow wiki that is being merged into llvm_notes.txt. Simply dropping this code onto python-dev without a guide to it would be unacceptable. llvm_notes.txt also details available instrumentation, useful to CPython developers who are investigating performance changes. Thanks, Collin Winter _______________________________________________ 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
