FAQ
Yesterday Jason Coombs, Barry Warsaw, and I met for about 6 hours of
sprinting on PEP 420.

We added a test framework and added tests for namespace packages using
the filesystem loader and zipimport loader. We flushed out a bug in
zipimport's namespace finder support as part of this.

We identified the following issues which need to get resolved before the
PEP is ruled on:

1. What about __file__? Barry is currently discussing this in the other
thread.

2: Parent path modification detection. I'm still thinking this one over.
I'm going to look into whipping up a sample implementation.

I think these can all be resolved this weekend, so we'll ask that a
ruling be made on the PEP next week. Please let me know if you have
other PEP (not implementation) concerns.


There are also these quality of implementation issues that I don't think
need to get addressed before PEP 420 is ruled on:

1. Documentation.

2. More tests. We need to test namespace packages as sub-packages, not
just top level.

3. The zipimport finder currently looks for "path/" to detect if a
'directory' exists and could be a namespace portion. However, this is a
valid zip file:
Archive: namespace_pkgs/missing_directory.zip
Length Date Time Name
--------- ---------- ----- ----
0 2012-05-04 04:45 bar/
35 2012-05-04 04:45 bar/two.py
26 2012-05-04 04:45 foo/one.py
--------- -------
61 3 files
The current code will treat "bar" as a possible portion, but not "foo".
We discussed a number of ways to address this, but I'm unconvinced
they're worth the hassle and runtime expense. But in any event, it's an
issue for another day and doesn't affect the PEP's acceptance one way or
the other.

All of the code is checked in to features/pep-420.

Eric.

Search Discussions

  • PJ Eby at May 4, 2012 at 4:50 pm

    On Fri, May 4, 2012 at 11:13 AM, Eric V. Smith wrote:

    3. The zipimport finder currently looks for "path/" to detect if a
    'directory' exists and could be a namespace portion. However, this is a
    valid zip file:
    Archive: namespace_pkgs/missing_directory.zip
    Length Date Time Name
    --------- ---------- ----- ----
    0 2012-05-04 04:45 bar/
    35 2012-05-04 04:45 bar/two.py
    26 2012-05-04 04:45 foo/one.py
    --------- -------
    61 3 files
    The current code will treat "bar" as a possible portion, but not "foo".
    We discussed a number of ways to address this, but I'm unconvinced
    they're worth the hassle and runtime expense. But in any event, it's an
    issue for another day and doesn't affect the PEP's acceptance one way or
    the other.
    FYI, the zip files produced by distutils do not include the empty
    directory. Actually, I'm not sure when/where I've ever seen an empty
    directory listed in a zipfile.

    IMO, the no-explicit-directory case should be handled, if for no other
    reason than that it shouldn't randomly break depending on which archiving
    tool you used to create the zipfile with.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/import-sig/attachments/20120504/f73d8a36/attachment.html>
  • Eric V. Smith at May 4, 2012 at 4:57 pm

    On 05/04/2012 12:50 PM, PJ Eby wrote:
    On Fri, May 4, 2012 at 11:13 AM, Eric V. Smith <eric at trueblade.com
    wrote:

    3. The zipimport finder currently looks for "path/" to detect if a
    'directory' exists and could be a namespace portion. However, this is a
    valid zip file:
    Archive: namespace_pkgs/missing_directory.zip
    Length Date Time Name
    --------- ---------- ----- ----
    0 2012-05-04 04:45 bar/
    35 2012-05-04 04:45 bar/two.py
    26 2012-05-04 04:45 foo/one.py
    --------- -------
    61 3 files
    The current code will treat "bar" as a possible portion, but not "foo".
    We discussed a number of ways to address this, but I'm unconvinced
    they're worth the hassle and runtime expense. But in any event, it's an
    issue for another day and doesn't affect the PEP's acceptance one way or
    the other.


    FYI, the zip files produced by distutils do not include the empty
    directory. Actually, I'm not sure when/where I've ever seen an empty
    directory listed in a zipfile.
    Interesting, thanks for the info.

    They are created if you use "zip -r" from a Linux box and it recurses
    into the directory. But it's definitely possible to create them without
    the empty directory if you explicitly list the files, or of course you
    can just delete them after the fact (which is what I did here).
    IMO, the no-explicit-directory case should be handled, if for no other
    reason than that it shouldn't randomly break depending on which
    archiving tool you used to create the zipfile with.
    I agree. It's just that I'm not likely to get to it in the next few
    weeks. Hopefully I'll delay long enough that someone smarter than me
    will rewrite zipimport in Python
    (http://bugs.python.org/issue14678?@ok_message=issue 14678). I started
    with Python so I wouldn't have to write any more C!

    Eric.
  • Martin at May 4, 2012 at 5:00 pm

    IMO, the no-explicit-directory case should be handled, if for no other
    reason than that it shouldn't randomly break depending on which archiving
    tool you used to create the zipfile with.
    I agree. IIRC, the zip importer creates a cached list/dictionary of the
    zip directory, anyway; while doing so, it could easily synthesize the
    directory names.

    Regards,
    Martin
  • Eric V. Smith at May 4, 2012 at 5:07 pm

    On 05/04/2012 01:00 PM, martin at v.loewis.de wrote:
    IMO, the no-explicit-directory case should be handled, if for no other
    reason than that it shouldn't randomly break depending on which archiving
    tool you used to create the zipfile with.
    I agree. IIRC, the zip importer creates a cached list/dictionary of the
    zip directory, anyway; while doing so, it could easily synthesize the
    directory names.
    Correct. It builds a dictionary. It could create another dictionary (or
    set is all I really need) with all directories, found or synthesized.

    Eric.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupimport-sig @
categoriespython
postedMay 4, '12 at 3:13p
activeMay 4, '12 at 5:07p
posts5
users3
websitepython.org

3 users in discussion

Eric V. Smith: 3 posts Martin: 1 post PJ Eby: 1 post

People

Translate

site design / logo © 2018 Grokbase