[Python-Dev] versioned .so files for Python 3.2

Barry Warsaw barry at python.org
Thu Jun 24 23:23:02 CEST 2010


On Jun 24, 2010, at 08:50 PM, Éric Araujo wrote:

>Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
>> Other possible approaches:
>>  * Extend the distutils API so that the .so file extension can be passed in,
>>    instead of being essentially hardcoded to what Python's Makefile contains.
>
>Third-party code rely on Distutils internal quirks, so it’s frozen. Feel
>free to open a bug against Distutils2 on the Python tracker if that
>would be generally useful.

Depending on how strict this constraint is, it could make things more
difficult.  I can control what shared library file names Python will load
statically, but in order to support PEP 384 I think I need to be able to
control what file extensions build_ext writes.

My updated patch does this in a backward compatible way.  Of course, distutils
hacks have their tentacles all up in the distutils internals, so maybe my
patch will break something after all.  I can think of a few even hackier ways
to work around that if necessary.

My updated patch:
 * Adds an optional argument to build_ext.get_ext_fullpath() and
   build_ext.get_ext_filename().  This extra argument is the Extension
   instance being built.  (Boy, just in case anyone's already playing with the
   time machine, it sure would have been nice if these methods had originally
   just taken the Extension instance and dug out ext.name instead of passing
   the string in.)
 * Adds an optional new keyword argument to the Extension class, called
   so_abi_tag.  If given, this overrides the Makefile $SO variable extension.

What this means is that with no changes, a non-PEP 384 compliant extension
module wouldn't have to change anything:

setup(
    name='stupid',
    version='0.0',
    packages=['stupid', 'stupid.tests'],
    ext_modules=[Extension('_stupid',
                           ['src/stupid.c'],
                           )],
    test_suite='stupid.tests',
    )

With a Python built like so:

    % SOABI=cpython-32 ./configure

you'd end up with a _stupid.cpython-32.so module.

However, if you knew your extension module was PEP 384 compliant, and could be
shared on >=Python 3.2, you would do:

setup(
    name='stupid',
    version='0.0',
    packages=['stupid', 'stupid.tests'],
    ext_modules=[Extension('_stupid',
                           ['src/stupid.c'],
                           so_abi_tag='',
                           )],
    test_suite='stupid.tests',
    )

and now you'd end up with _stupid.so, which I propose to mean it's PEP 384 ABI
compliant.  (There may not be any other use case than so_abi_tag='' or
so_abi_tag=None, in which case, the Extension keyword *might* be better off as
a boolean.)

Now of course PEP 384 isn't implemented, so it's a bit of a moot point.  But
if some form of versioned .so file naming is accepted for Python 3.2, I'll
update PEP 384 with possible solutions.

-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/20100624/14b9b0be/attachment.pgp>


More information about the Python-Dev mailing list