There are some minor typos in the docs. The section zipfile has twp typos:

exception zipfile.BadZipfile
    The error raised for bad ZIP files (old name: zipfile.error).

this should be

exception zipfile.BadZipFile
    The error raised for bad ZIP files (old name: zipfile.error).

Note: There needs to be a capital F in the exception class name BadZipFile.


There's also a typo in the sentence "Decryption is extremely slow as it
is implemented in native python rather than C." which should be
"Decryption is extremely slow as it is implemented in native Python
rather than C." This sentence is found just above the previous
BadZipfile typo.

Note: The word 'python' is needed to be capitalized.


These typos exist since the creation of the zipfile docs. Please correct
the docs for the selected versions. Thank you.

BadZipfile is actually the correct name of the exception.

Fixed the other nit in r76376.

Thanks for upcassing 'Python'.

I have to ask you why are all other classes named in the form of
...ZipFile, like
- exception: LargeZipFile
- class: ZipFile
- class: PyZipFile

Please at least consider of making the class BadZipfile consistent to
other classes and let it be renamed to BadZipFile. Thank you again.

I suggest renaming the class from BadZipfile to BadZipFile. We have a
class named LargeZipFile. It would make sence to have the previously
mentioned class named as BadZipFile then. What is your verdict on that?

The old name could be deprecated and replaced by the right one, but as
Eric Smith mentioned on #python-dev, the class with the old name can't
be removed because - even if unlikely - the object might exist in a pickle.
So we can either live with the wrong name or deprecate it, fix the
places where it's used and live with a deprecated version that can't be
removed.

I am merely speaking of renaming the class name from BadZipfile to
BadZipFile. 

class BadZipFile(exceptions.Exception):
    # etc.


Only the name is fixed at class definition. I am aiming for that in this
bug report. And then every other BadZipfile should be fixed to
BadZipFile. Is that doable?

It might be doable for Python and its stdlib, but all the programs and
modules that are using the old name will start raising errors if they
don't find the old name anymore.
If the old name is deprecated for at least one Python version (e.g.
2.7/3.2), these programs can fix it and then, after a few versions (e.g.
3.3), the old name can finally be removed.
There is still the pickle issue, even if IMHO it's so unlikely that it
shouldn't be relevant.

I made a patch which fixes the BadZipfile issue. Please take a look and
decide whether you'll toss it or use it. Maybe it'll come handy some
other time in the future.

Your patch need to include an alias (BadZipfile = BadZipFile) to
preserve compatibility with old pickles, as explains msg95477.

Cheers

While the mismatched casing is unfortunate, I don't think changing it
for the sake of aesthetics is a good deal given that many existing
programs will have to be converted to the new spelling.

Unless we are going to add an alias for BadZipfile, I'll close this as won't fix.

I'm reopening this and I am making it a feature request for Python 3.2

Boštjan, you need to update your patch to add the missing alias to the old name, as well as docs and test updates.

I’m +0 on the change.

I am -1 for the alias. I want that this gets renamed in Python 3.2, not
aliased. I don't care about old pickles. Anyway, who has BadZipfile object
pickled? Just incorporate my patch and fix the docs and any test
cases/units. Thanks.

On Wed, Oct 27, 2010 at 10:43 PM, Éric Araujo <report@bugs.python.org>wrote:

>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> Boštjan, you need to update your patch to add the missing alias to the old
> name, as well as docs and test updates.
>
> I’m +0 on the change.
>
> ----------
> stage: committed/rejected -> patch review
> title: Documentation typos found in "zipfile — Work with ZIP archives" ->
> Rename BadZipfile to BadZipFile for consistency
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

You may "not care" about backwards compatibility, but introducing a breaking change in 3.2 for mere style-conformity is not OK, IMO. If the patcher insists on it being a breaking change, it should be rejected.

FWIW, this casing is sufficiently bizarre and inconsistent in the module itself, that it seems clearly wrong and likely to produce difficulties for people using it-- so although I'm not upgrading to Python3 anytime soon, I'd really like to change my code to be BadZipFile when I do, so I'd be +1 with an alias. :)

No alias. Be stubborn and let the stdlib die in inconsistency.

On Thu, Oct 28, 2010 at 2:11 AM, Stephen Hansen <report@bugs.python.org>wrote:

>
> Stephen Hansen <me+python@ixokai.io <me%2Bpython@ixokai.io>> added the
> comment:
>
> You may "not care" about backwards compatibility, but introducing a
> breaking change in 3.2 for mere style-conformity is not OK, IMO. If the
> patcher insists on it being a breaking change, it should be rejected.
>
> FWIW, this casing is sufficiently bizarre and inconsistent in the module
> itself, that it seems clearly wrong and likely to produce difficulties for
> people using it-- so although I'm not upgrading to Python3 anytime soon, I'd
> really like to change my code to be BadZipFile when I do, so I'd be +1 with
> an alias. :)
>
> ----------
> nosy: +ixokai
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

Considering I do use zipfiles a lot, I slightly care about this (at least, eventually)-- I'm attaching a new patch, with doc and test changes as well (and the compatibility alias).

What convinced me was looking at test_zipfile, and noticing how often it actually confused the issue in comments at least, between typing BadZipfile and BadZipFile.

Dunno if I worded the doc-change well, so you may want to adjust that.

Oh: and I tested it against branches/py3k in the head, it applies cleanly and builds, and test_zipfile runs without error.

Applied after review in r85874. (Please make sure your patches don't have trailing whitespace.)

A “BadZipZile” in the patch made it to Subversion :)  Fixed in r85891.

Thanks for the catch!

Is the trailing whitespace problem solved? Please make sure everything is
correct and that no more typos occur for this issue. And I am the original
patch author, so mention my name (Boštjan Mejak) in the NEWS file. Thanks.

On Thu, Oct 28, 2010 at 8:42 AM, Georg Brandl <report@bugs.python.org>wrote:

>
> Georg Brandl <georg@python.org> added the comment:
>
> Applied after review in r85874. (Please make sure your patches don't have
> trailing whitespace.)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

a) I already removed the whitespace before committing.  The pre-commit hook wouldn't even allow committing that.

b) I don't think constant refusal to submit a patch in the way we request earns you a place in the acknowledgements.

> Is the trailing whitespace problem solved?
You can follow the link to the revision to see that it is.  Georg’s message implied this, too.

> Please make sure everything is correct and that no more typos occur for this issue.
We do.

> And I am the original patch author, so mention my name (Boštjan Mejak) in the NEWS file. Thanks.
We don’t add names for very small patches like this one.

(P.S. Would you be so kind as to follow some netiquette in the tracker?  HTML email creates noisy unnamed attachments, and top-posting is redundant and hard to read.  Thanks in advance.)

Then disable the tracker's ability to post messages via POP/IMAP. Just block
those protocols in the tracker and you won't see any gibberish anymore. ;)

On Thu, Oct 28, 2010 at 4:05 PM, Éric Araujo <report@bugs.python.org> wrote:

>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> > Is the trailing whitespace problem solved?
> You can follow the link to the revision to see that it is.  Georg’s message
> implied this, too.
>
> > Please make sure everything is correct and that no more typos occur for
> this issue.
> We do.
>
> > And I am the original patch author, so mention my name (Boštjan Mejak) in
> the NEWS file. Thanks.
> We don’t add names for very small patches like this one.
>
> (P.S. Would you be so kind as to follow some netiquette in the tracker?
>  HTML email creates noisy unnamed attachments, and top-posting is redundant
> and hard to read.  Thanks in advance.)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>