This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, barry, doko, dstufft, eric.snow, lemburg, ncoghlan, ned.deily, pitrou, python-dev, steve.dower, tim.golden, zach.ware
Date 2015-04-16.23:35:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <5530473E.7080307@egenix.com>
In-reply-to <1429224716.48.0.929747293252.issue22980@psf.upfronthosting.co.za>
Content
On 17.04.2015 00:51, Donald Stufft wrote:
> 
>> Since you need special support for such ZIP files (either using dlopen
>> hacks or temporarily extracting them), you might as well deal with
>> the platform dependencies in that handler. No need to force the
>> platform tags on all your .so file for no apparent reason.
> 
> There are other reasons as have already been mentioned, this is just yet
> another reason (and on it's own I'd agree it's not a sufficiently compelling
> use case), but when I see a pattern of things which all need the same thing
> then that speaks to me that it should live someplace centrally instead of
> having each one reimplement it. 

Sure, but whatever the central implementation is going to be,
it doesn't necessarily have to require sticking platform ABI flags
on all .so files, even those which will never need to be installed
side-by-side. The more paths you need to stat when searching
a shared mod, the slower Python will get.

There's a very simple trick which some packages used in the
past for sumo distributions - you simply modify the __path__
attribute of the package to point to the platform dependent
files in the __init__.py file and Python will then automagically
use the right C extensions.

To simplify this, the platform triplets and other platform ABI flags
could be made available via the sys or sysconfig module for importers
and other tools to pick up.
History
Date User Action Args
2015-04-16 23:35:34lemburgsetrecipients: + lemburg, barry, doko, ncoghlan, pitrou, tim.golden, ned.deily, Arfrever, python-dev, eric.snow, zach.ware, steve.dower, dstufft
2015-04-16 23:35:34lemburglinkissue22980 messages
2015-04-16 23:35:33lemburgcreate