Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Deprecate some of the module file formats #58248

Closed
pitrou opened this issue Feb 17, 2012 · 10 comments
Closed

Deprecate some of the module file formats #58248

pitrou opened this issue Feb 17, 2012 · 10 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage stdlib Python modules in the Lib dir

Comments

@pitrou
Copy link
Member

pitrou commented Feb 17, 2012

BPO 14040
Nosy @loewis, @warsaw, @brettcannon, @pitrou, @merwok, @davidmalcolm, @ericsnowcurrently
Files
  • impsuffix.patch
  • impsuffix2.patch
  • removesuffixes.patch
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2012-02-20.18:54:02.301>
created_at = <Date 2012-02-17.13:36:35.966>
labels = ['interpreter-core', 'library', 'performance']
title = 'Deprecate some of the module file formats'
updated_at = <Date 2012-02-20.18:54:02.299>
user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2012-02-20.18:54:02.299>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2012-02-20.18:54:02.301>
closer = 'pitrou'
components = ['Interpreter Core', 'Library (Lib)']
creation = <Date 2012-02-17.13:36:35.966>
creator = 'pitrou'
dependencies = []
files = ['24544', '24559', '24564']
hgrepos = []
issue_num = 14040
keywords = ['patch']
message_count = 10.0
messages = ['153544', '153546', '153550', '153651', '153652', '153662', '153712', '153727', '153795', '153797']
nosy_count = 12.0
nosy_names = ['loewis', 'barry', 'brett.cannon', 'pitrou', 'schmir', 'nadeem.vawda', 'eric.araujo', 'Arfrever', 'dmalcolm', 'neologix', 'python-dev', 'eric.snow']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue14040'
versions = ['Python 3.3']
    @pitrou
    Copy link
    Member Author

    pitrou commented Feb 17, 2012

    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.

    @pitrou pitrou added interpreter-core (Objects, Python, Grammar, and Parser dirs) stdlib Python modules in the Lib dir performance Performance or resource usage labels Feb 17, 2012
    @brettcannon
    Copy link
    Member

    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.

    @warsaw
    Copy link
    Member

    warsaw commented Feb 17, 2012

    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.

    @pitrou
    Copy link
    Member Author

    pitrou commented Feb 18, 2012

    Here is a patch with tests.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Feb 18, 2012

    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.

    @brettcannon
    Copy link
    Member

    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. =)

    @pitrou
    Copy link
    Member Author

    pitrou commented Feb 19, 2012

    Here is a patch simply removing the suffixes.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Feb 19, 2012

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

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Feb 20, 2012

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

    @pitrou
    Copy link
    Member Author

    pitrou commented Feb 20, 2012

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

    @pitrou pitrou closed this as completed Feb 20, 2012
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage stdlib Python modules in the Lib dir
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @brettcannon @warsaw @pitrou