On Jul 08, 2010, at 01:47 AM, Matthias Klose wrote:
On 07.07.2010 20:40, Barry Warsaw wrote:
Getting back to this after the US holiday. Thanks for running these numbers Scott. I've opened a bug in the Python tracker and attached my latest patch:
http://bugs.python.org/issue9193
The one difference from previous versions of the patch is that the .so tag is now settable via "./configure --with-so-abi-tag=foo". This would generate shared libs like _multiprocessing.foo.so.
- imo, it's wrong to lookup _multiprocessing.so first, before looking up _multiprocessing.foo.so (at least for the use case to put the extensions for multiple python versions into one directory).
Good point.
- why is the flexibility of specifying the "foo" needed? The naming for the __pycache__ files is fixed, why have it configurable for extensions?
The 'foo' part in the shared library name is equivalent to the <tag> part in __pycache__/baz.<tag>.pyc, not specifically the __pycache__ part. Specifying the <tag> is necessary because extension modules built for Python 3.2 will not be compatible with extension modules built for Python 3.3 (in the absence of PEP 384), but they will live in the same directory. -Barry