Robert de Vries added the comment:

My use case is decrypting files of 100's of megabytes. This is so slow that it 
is quite useless. About an hour or so.

I do agree that the encryption is worthless, but that is not important for my 
use case where I want to discourage people from reverse engineering the 
If it is so dangerous as some people have pointed out, it should be removed at 
the cost of not supporting a standard feature of ZIP files.
In my opinion you either support a feature and you support it good (efficient) 
or you don't. As it stands now, users will be disappointed in using a supported 

Some people argue that adding C code to Python is dangerous as it will lead to 
bugs, vulnerabilities etc.
You could dismiss every addition with C code to Python with this argument, so 
there must be some positive aspects to outweigh the negative side. The negative 
side is fairly small (50 lines of very simple C code), plus some standard 
Python glue code.
The benefit is a 100 fold increase in performance and the removal of 1 line of 
documentation telling that this feature is extremely slow.
(patch attached)

Added file:

Python tracker <>
Python-bugs-list mailing list

Reply via email to