Repository navigation
Rename BadZipfile to BadZipFile for consistency #51600
Description
| BPO | 7351 |
|---|---|
| Nosy | @birkenfeld, @pitrou, @ezio-melotti, @merwok |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2010-10-28.06:39:44.829>
created_at = <Date 2009-11-18.19:12:34.863>
labels = ['interpreter-core', 'type-feature']
title = 'Rename BadZipfile to BadZipFile for consistency'
updated_at = <Date 2010-10-28.14:14:18.409>
user = 'https://bugs.python.org/Retro'bugs.python.org fields:
activity = <Date 2010-10-28.14:14:18.409>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = <Date 2010-10-28.06:39:44.829>
closer = 'georg.brandl'
components = ['Interpreter Core']
creation = <Date 2009-11-18.19:12:34.863>
creator = 'Retro'
dependencies = []
files = ['15365', '19389']
hgrepos = []
issue_num = 7351
keywords = ['patch']
message_count = 25.0
messages = ['95442', '95445', '95453', '95473', '95477', '95485', '95488', '95505', '96690', '96691', '100182', '119730', '119734', '119744', '119745', '119746', '119747', '119748', '119758', '119780', '119782', '119783', '119784', '119785', '119787']
nosy_count = 6.0
nosy_names = ['georg.brandl', 'ixokai', 'pitrou', 'ezio.melotti', 'eric.araujo', 'Retro']
pr_nums = []
priority = 'low'
resolution = 'fixed'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue7351'
versions = ['Python 3.2']
Activity
Retro commentedon Nov 18, 2009
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.
birkenfeld commentedon Nov 18, 2009
BadZipfile is actually the correct name of the exception.
Fixed the other nit in r76376.
Retro commentedon Nov 18, 2009
Thanks for upcassing 'Python'.
I have to ask you why are all other classes named in the form of
...ZipFile, like
Please at least consider of making the class BadZipfile consistent to
other classes and let it be renamed to BadZipFile. Thank you again.
Retro commentedon Nov 19, 2009
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?
ezio-melotti commentedon Nov 19, 2009
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.
Retro commentedon Nov 19, 2009
I am merely speaking of renaming the class name from BadZipfile to
BadZipFile.
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?
ezio-melotti commentedon Nov 19, 2009
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.
Retro commentedon Nov 19, 2009
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.
merwok commentedon Dec 20, 2009
Your patch need to include an alias (BadZipfile = BadZipFile) to
preserve compatibility with old pickles, as explains msg95477.
Cheers
pitrou commentedon Dec 20, 2009
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.
ezio-melotti commentedon Feb 27, 2010
Unless we are going to add an alias for BadZipfile, I'll close this as won't fix.
8 remaining items
[-]Documentation typos found in "zipfile — Work with ZIP archives"[/-][+]Rename BadZipfile to BadZipFile for consistency[/+]Retro commentedon Oct 27, 2010
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:
ixokai commentedon Oct 28, 2010
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. :)
Retro commentedon Oct 28, 2010
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:
ixokai commentedon Oct 28, 2010
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.
ixokai commentedon Oct 28, 2010
Oh: and I tested it against branches/py3k in the head, it applies cleanly and builds, and test_zipfile runs without error.
birkenfeld commentedon Oct 28, 2010
Applied after review in r85874. (Please make sure your patches don't have trailing whitespace.)
merwok commentedon Oct 28, 2010
A “BadZipZile” in the patch made it to Subversion :) Fixed in r85891.
birkenfeld commentedon Oct 28, 2010
Thanks for the catch!
Retro commentedon Oct 28, 2010
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:
birkenfeld commentedon Oct 28, 2010
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.
merwok commentedon Oct 28, 2010
(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.)
Retro commentedon Oct 28, 2010
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: