Skip to content

Conversation

@peterbe
Copy link

@peterbe peterbe commented Feb 1, 2018

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

zipfile.ZipFile class's extractall method allows the list of members to be
unset and if it is, defaults to the list of file *names* in the zip. When
sent to _extract_member that file name needs to be rewrapped as a ZipInfo
instance. The ZipInfo instances is already available inside extractall and
can be re-used.
@peterbe peterbe force-pushed the use-infolist-for-zipefileextractall branch from d802d06 to 1bb1df5 Compare February 1, 2018 15:23
Lib/zipfile.py Outdated
directory. `path' specifies a different directory to extract to.
`members' is optional and must be a subset of the list returned
by namelist().
by infolist().
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think more doc is needed (here and in the ReST documentation) to make things clear. The code change in this PR does not change the function interface: people could pass a list of names or a list of ZipInfos before (thanks to extractall calling _extract_member which supports both), and they’re still able to do that after the change.

Maybe the doc could be explicit about these two options? Instead of naming directly namelist or infolist (and letting people think that members must be strings or must be ZipInfos), something like «members is optional and must contain strings or ZipInfo objects corresponding to valid entries (i.e. a subset of the list returned by namelist or infolist)».

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I juggled the idea but everything I attempted just got long winded and more confusing. Just saying infolist or namelist is both correct and really brief. Too brief?

@merwok
Copy link
Member

merwok commented Oct 19, 2020

Status: There is a question on the bug report about a behaviour change that needs to be addressed.

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Aug 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting review stale Stale PR or inactive for long period of time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants