Author Jim.Jewett
Recipients Jim.Jewett, NewerCookie, alanmcintyre, amaury.forgeotdarc, apolkosnik, berker.peksag, chuck, ethan.furman, francismb, georg.brandl, gregory.p.smith, ncoghlan, ronaldoussoren, serhiy.storchaka, terry.reedy
Date 2014-04-30.22:13:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CA+OGgf4oRngE2ONPc4WseaFkjMZ5bY=pJcsoQ9tfj7JEP0WZSQ@mail.gmail.com>
In-reply-to <1398885110.1.0.45638107752.issue6839@psf.upfronthosting.co.za>
Content
On Wed, Apr 30, 2014 at 3:11 PM, Adam Polkosnik

> I've got some test cases where the zlib_forward_slash.patch doesn't cut it.

My recommendation (and I could be convinced otherwise) would be to replace

    if fname_str != zinfo.orig_filename:
        raise ...

with something more like

    self.filename_check(fname_str,  zinfo.orig_filename)

and a default implementation of filename_check that does nothing if
they're equal; calls the slash replace (since the standard supports
that correction); does nothing else if they're now equal; emits a
warning (or prints, in 2.7.6) otherwise.

In 2.7.6, you would have to keep the new methods private, but in 3.5,
users could override filename_check to handle the windows path
normalization, or whatever other problems you have documented.
History
Date User Action Args
2014-04-30 22:13:45Jim.Jewettsetrecipients: + Jim.Jewett, georg.brandl, terry.reedy, gregory.p.smith, ronaldoussoren, amaury.forgeotdarc, ncoghlan, alanmcintyre, NewerCookie, chuck, ethan.furman, francismb, berker.peksag, serhiy.storchaka, apolkosnik
2014-04-30 22:13:45Jim.Jewettlinkissue6839 messages
2014-04-30 22:13:45Jim.Jewettcreate