This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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