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 contents. 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 feature. 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: http://bugs.python.org/file27881/doc.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10030> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
