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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100709/e0349cc0/attachment-0001.pgp>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4