Refactor zipfile to ease subclassing and enhancement

[e7453047-905b-492e-9222-15edd130d637]

BPO	37538
Nosy	@serhiy-storchaka, @danifus
PRs	python/cpython#14957

^{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: ```python assignee = None closed_at = None created_at = labels = ['type-feature', 'library', '3.9'] title = 'Refactor zipfile to ease subclassing and enhancement' updated_at = user = 'https://github.com/danifus' ``` bugs.python.org fields: ```python activity = actor = 'dhillier' assignee = 'none' closed = False closed_date = None closer = None components = ['Library (Lib)'] creation = creator = 'dhillier' dependencies = [] files = [] hgrepos = [] issue_num = 37538 keywords = ['patch'] message_count = 4.0 messages = ['347604', '347609', '347613', '347972'] nosy_count = 2.0 nosy_names = ['serhiy.storchaka', 'dhillier'] pr_nums = ['14957'] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue37538' versions = ['Python 3.9'] ```

[e7453047-905b-492e-9222-15edd130d637]

I've written https://github.com/danifus/pyzipper which incorporates a refactor of zipfile.py in order to support winzip AES encryption. I don't intend to include the crypto code but I would like to incorporate the refactor to help others subclass and extend the objects found in zipfile.py

For a longer description of the general approach I've taken to the refactor, see the python-ideas thread: https://mail.python.org/archives/list/python-ideas@python.org/thread/QCKHI5JYMKOPMIF6Q2NI7JIFHV6KO746/#QCKHI5JYMKOPMIF6Q2NI7JIFHV6KO746

[e7453047-905b-492e-9222-15edd130d637]

I've started a branch on my github fork if anyone wants to follow along.

https://github.com/danifus/cpython/tree/zipfile_refactor

Is there a better way to manage this in terms of review and suggestions as I add more commits?

[serhiy-storchaka]

I did not read your code yet, but I think it is the right way.

If your btanch contains changes which you do not want to commit to CPython, but which makes the purpose of other changes clearer, you can create a PR against the master in your fork

[e7453047-905b-492e-9222-15edd130d637]

Hi,

Here is a pull request against my fork:

https://github.com/danifus/cpython/pull/1/files

The overall behaviour of zipfile remains the same and I've tried to call out any behaviour changes in the extended commit messages (usually with ** markers).

There is another branch (https://github.com/danifus/cpython/tree/zipfile_refactor_2) which has a couple of extra commits which slightly changes some functionality.

Any review would be greatly appreciated! Happy to make any changes to the code or general approach taken.

Thanks, Dan