homepage

Stating module files of the form "xxxmodule.so" consumes all 1/3 of stat calls at startup. Looking at the site-packages folders on my machine, both for 2.7 and 3.2, reveals no C extension that follows such naming.
This patch deprecates such module namings, so that they can be removed in a later version.

Patch looks fine, although there aren't any tests. At least for importlib you can simply use a finder test for extension modules to verify the warning is triggered. That way you can create an empty module with the expected naming rather than worry about compiling an extension module.

On Feb 17, 2012, at 01:36 PM, Antoine Pitrou wrote:
>Stating module files of the form "xxxmodule.so" consumes all 1/3 of stat
>calls at startup. Looking at the site-packages folders on my machine, both
>for 2.7 and 3.2, reveals no C extension that follows such naming.
>
>This patch deprecates such module namings, so that they can be removed in a
>later version.
+1
In Debian/Ubuntu I have seen some third party extensions (not built with
distutils) that still use this naming convention in their Python 3 extension
module, but it's usually pretty easy to rename them to PEP 3149 style names in
the platform build scripts. I think it's a great idea to eventually get rid
of the untagged names altogether, and saving some stat calls is added benefit.

Here is a patch with tests.

In this case, I propose to drop the feature without deprecation. It is very easy to adjust the build process of packages that still use the feature, and even end users can rename the files.
If you want to improve ease-of-use, you could still do the stat calls, and record whether a file would have been imported. If then the import fails, put a message into the import error saying the /some/where/somemodule.so was ignored because the file name is no longer supported.

I like Martin's suggestion of simply throwing an error. But then again I also really like his idea of simply not warning since it's easier. =)

Here is a patch simply removing the suffixes.

I'm in favour of the removesuffixes.patch. However, it will need to be accompanied with a whatsnew change.

New changeset 42f61304f77d by Antoine Pitrou in branch 'default':
Issue #14040: Remove rarely used file name suffixes for C extensions (under POSIX mainly).
http://hg.python.org/cpython/rev/42f61304f77d 

I've now committed the suffix removal patch with a what's new entry. Thanks!