Author rhdv
Recipients pitrou, r.david.murray, rhdv, serhiy.storchaka, shashank
Date 2012-11-04.13:20:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1352035220.65.0.948092193536.issue10030@psf.upfronthosting.co.za>
In-reply-to
Content
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)
History
Date User Action Args
2012-11-04 13:20:20rhdvsetrecipients: + rhdv, pitrou, r.david.murray, shashank, serhiy.storchaka
2012-11-04 13:20:20rhdvsetmessageid: <1352035220.65.0.948092193536.issue10030@psf.upfronthosting.co.za>
2012-11-04 13:20:20rhdvlinkissue10030 messages
2012-11-04 13:20:20rhdvcreate