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
signature.asc
Description: PGP signature
_______________________________________________ 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
