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 paul.moore
Recipients irmen, paul.moore, serhiy.storchaka
Date 2017-08-11.09:41:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1502444502.23.0.599464734555.issue31072@psf.upfronthosting.co.za>
In-reply-to
Content
Zipapp uses path objects throughout, so making the filter function take a path object is consistent with that. I guess modifying PyZipFile to take either a string or a path object would be possible.

As for the relative path, that's deliberate as I expect that a common use case will be to exclude a directory, and doing that via

    lambda pth: pth.parts[0] != 'dir_to_exclude'

is a simple possibility. Having to do this with an absolute path would just require the user to make the path relative, and we've already done that in zipapp so why duplicate the work?

So I guess I'm saying I want to keep both those choices. Do you think this is a sufficient problem that we should *not* use the same name? Any suggestions on a better name (or should we stick with the original ``include_file``)?
History
Date User Action Args
2017-08-11 09:41:42paul.mooresetrecipients: + paul.moore, irmen, serhiy.storchaka
2017-08-11 09:41:42paul.mooresetmessageid: <1502444502.23.0.599464734555.issue31072@psf.upfronthosting.co.za>
2017-08-11 09:41:42paul.moorelinkissue31072 messages
2017-08-11 09:41:41paul.moorecreate