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

Remove inconsistent behavior between import and zipimport #42549

Closed
acidbase mannequin opened this issue Nov 3, 2005 · 11 comments
Closed

Remove inconsistent behavior between import and zipimport #42549

acidbase mannequin opened this issue Nov 3, 2005 · 11 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@acidbase
Copy link
Mannequin

acidbase mannequin commented Nov 3, 2005

BPO 1346572
Nosy @loewis, @brettcannon, @ncoghlan, @merwok
Files
  • patch_import.diff: Patch to 'fix' this inconsitent behavior import/zipimport
  • 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-04-22.17:14:45.016>
    created_at = <Date 2005-11-03.03:43:17.000>
    labels = ['interpreter-core']
    title = 'Remove inconsistent behavior between import and zipimport'
    updated_at = <Date 2012-04-22.17:14:45.012>
    user = 'https://bugs.python.org/acidbase'

    bugs.python.org fields:

    activity = <Date 2012-04-22.17:14:45.012>
    actor = 'eric.araujo'
    assignee = 'none'
    closed = True
    closed_date = <Date 2012-04-22.17:14:45.016>
    closer = 'eric.araujo'
    components = ['Interpreter Core']
    creation = <Date 2005-11-03.03:43:17.000>
    creator = 'acidbase'
    dependencies = []
    files = ['6851']
    hgrepos = []
    issue_num = 1346572
    keywords = ['patch']
    message_count = 11.0
    messages = ['48962', '48963', '154681', '154682', '154698', '154703', '154711', '154733', '154738', '154739', '154741']
    nosy_count = 5.0
    nosy_names = ['loewis', 'brett.cannon', 'ncoghlan', 'acidbase', 'eric.araujo']
    pr_nums = []
    priority = 'normal'
    resolution = 'wont fix'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue1346572'
    versions = []

    @acidbase
    Copy link
    Mannequin Author

    acidbase mannequin commented Nov 3, 2005

    Look the inconsistent behavior:
    $ ls
    modulo_c.pyc modulo_o.pyo
    $ zip modulos.zip modulo_o.pyo modulo_c.pyc
    adding: modulo_o.pyo (deflated 38%)
    adding: modulo_c.pyc (deflated 38%)
    $ ls
    modulo_c.pyc modulo_o.pyo modulos.zip

    $ python2.4
    >>> import modulo_c
    modulo_c
    >>> import modulo_o
    ImportError: No module named modulo_o
    
    $ python2.4 -O
    >>> import modulo_c
    ImportError: No module named modulo_c
    >>> import modulo_o
    modulo_o
    $ rm *.pyc *.pyo
    $ ls
    modulos.zip
    $ PYTHONPATH=modulos.zip python2.4
    >>> import modulo_c
    modulo_c
    >>> import modulo_o
    modulo_o
    $ PYTHONPATH=modulos.zip python2.4 -O
    >>> import modulo_c
    modulo_c
    >>> import modulo_o
    modulo_o

    @acidbase acidbase mannequin closed this as completed Nov 3, 2005
    @acidbase acidbase mannequin added invalid interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Nov 3, 2005
    @acidbase acidbase mannequin closed this as completed Nov 3, 2005
    @acidbase acidbase mannequin added invalid interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Nov 3, 2005
    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Nov 5, 2006

    Logged In: YES
    user_id=21627

    The discussion on python-dev (both last year's and this
    year's) has shown that this is the wrong way of fixing the
    inconsistency. Instead, zipfile should stop importing .pyo
    files when -O isn't given. Rejecting the patch as invalid.

    @merwok
    Copy link
    Member

    merwok commented Mar 1, 2012

    Still an issue with 3.2: zipimport considers both pyc and pyo with or without -O.

    The discussion starts here: http://mail.python.org/pipermail/python-dev/2006-November/thread.html#69822

    (This was originally closed instead of asking for another fix because SourceForge separated bugs and patches.)

    @merwok merwok reopened this Mar 1, 2012
    @merwok merwok removed the invalid label Mar 1, 2012
    @merwok merwok reopened this Mar 1, 2012
    @merwok merwok removed the invalid label Mar 1, 2012
    @merwok
    Copy link
    Member

    merwok commented Mar 1, 2012

    I need to qualify something: I reproduced the bug with legacy/pre-PEP 3147/in-the-same-dir pyc and pyo files. One could argue that pycache directories in 3.2+ make this irrelevant and that it’s too late for 2.x.

    @brettcannon
    Copy link
    Member

    I like that argument. =) If this is not an issue in Python 3.3 then this should be closed as out of date since it will break code if it is changed.

    @merwok
    Copy link
    Member

    merwok commented Mar 1, 2012

    It entirely depends on how much you care about pyc-only/pyo-only zipfile distributions, and compatibility between zipimport and importlib (i.e. if you don’t plan on matching the zipimport bug in importlib, might as well fix zipimport in 2.7 and 3.2).

    @brettcannon
    Copy link
    Member

    I don't care about compatibility between zipimport and importlib.

    @merwok
    Copy link
    Member

    merwok commented Mar 2, 2012

    OK, I’m leaving this open until the next weekly report just in case someone interested comes here and weighs in, otherwise I’ll close as wontfix.

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Mar 2, 2012

    Does "compileall" generate both .pyc and .pyo by default? Or do you have to run it twice? If the latter, does pysetup handle that for you?

    MvL is correct that zipimport should ignore .pyo files when __debug__ is set and vice-versa, but the precompilation tools should also take care of generating both versions by default.

    @merwok
    Copy link
    Member

    merwok commented Mar 2, 2012

    Does "compileall" generate both .pyc and .pyo by default?
    python3 -m compileall generates pyc, python3 -O -m compileall pyo. Functions in py_compile and compileall gained an optimize argument in 3.2.

    does pysetup handle that for you?
    You’ll have to be more specific. Bytecode files can be created when building a bdist or on install from source. Packaging commands do not depend on the calling Python’s -O option, they have their own options to let users specify if they want pyc files, pyo, neither or both.

    MvL is correct that zipimport should ignore .pyo files when __debug__ is set and vice-versa, but the
    precompilation tools should also take care of generating both versions by default.
    Really? The behaviors of compileall and packaging seems better to me.

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Mar 2, 2012

    Status quo sounds fine then. +1 for closing it again.

    @merwok merwok closed this as completed Apr 22, 2012
    @merwok merwok closed this as completed Apr 22, 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
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs)
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants