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 loewis
Recipients barry, eric.smith, eric.snow, georg.brandl, giampaolo.rodola, loewis, nadeem.vawda, neologix, pitrou, rhettinger
Date 2011-12-05.21:42:49
SpamBayes Score 3.4381986e-10
Marked as misclassified No
Message-id <1323121370.59.0.00570445000435.issue11051@psf.upfronthosting.co.za>
In-reply-to
Content
> First, I don't understand why we need to check both "foo.so" and
> "foomodule.so".

Because we always did, i.e. changing it now may break backwards compatibility. Now, as for why we always had *module.so also: it may be that calling an extension module foo.so might not be feasible if it needs to link with a system library called foo.so (rather than libfoo.so). 

I don't know how serious this problem is in practice - we may consider deprecating-then-removing *module.so from the import machinery.

As for checking both "foo.so" and "foo.cpython-32m.so": that's for backwards compatibility also. Existing build processes may produce foo.so, as they did in previous Python versions (in particular, if they are not based on distutils, but, say, make). Unfortunately, PEP 3149 did not specify a deprecation scheduling. You could ask Barry - I suppose that was an oversight, and not actually deliberate.

Of course, with .cpython-32m.so being present, removing *module.so would be easy enough, except again for breaking existing projects which might use that name.
History
Date User Action Args
2011-12-05 21:42:50loewissetrecipients: + loewis, barry, georg.brandl, rhettinger, pitrou, eric.smith, giampaolo.rodola, nadeem.vawda, neologix, eric.snow
2011-12-05 21:42:50loewissetmessageid: <1323121370.59.0.00570445000435.issue11051@psf.upfronthosting.co.za>
2011-12-05 21:42:50loewislinkissue11051 messages
2011-12-05 21:42:49loewiscreate