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

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?

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

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