Patches item #1117398, was opened at 2005-02-06 17:39 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470
Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: cookielib LWPCookieJar and MozillaCookieJar exceptions Initial Comment: cookielib.LWPCookieJar and .MozillaCookieJar are documented to raise cookielib.LoadError on attempt to load an invalid cookies file, but do not. I think this should be backported to the 2.4 maintenance branch. Reason: I suspect more people will be bitten by the bug than will be bitten by the patch, since cookies files will rarely be invalid, so people are likely to have written except statements based on the docs in this case, rather than based on the actual exception that currently occurs. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2005-02-11 18:57 Message: Logged In: YES user_id=261020 I agree the backport (but not the trunk) should have LoadError derive from IOError. I'd be happy for comments to go in noting the change in all places where LoadError is raised, if that's considered good practice. Any committers reading: should I submit an updated patch with just those added comments? Should I submit a patch for the backport, with just that change plus the added (IOError) for backwards-compat.? (Jim: Besides the point for the matter at hand, but I should point out that the "pretty-for-printing" cookielib docs and the docstrings in cookielib.py form almost disjoint sets. Most of the documentation lives under Doc/lib, the stuff in the module source is the more obscure detail. And of course, you have just demonstrated to yourself how not reading the docs leaves you with an incomplete understanding of the intent, which can be useful! Not that I *ever* do that, of course ;-) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-11 16:06 Message: Logged In: YES user_id=764593 The first sentence was pointing out that many people (including me) never see the pretty-for-printing documentation, and even the html form isn't generally convenient when I'm actually programming. So I rely on the introspection tools. I see object names, signatures, and docstrings. If I need more information, I look at the code, which raises IOError. While I don't yet have code catching this particular error, I do write in a way that would break; it wouldn't have occurred to me to put both types of error in an except clause just in case it changed later. (Well, unless the docstring or at least a comment in the code itself warned me to.) So I would definately prefer that it remain (at least a subclass of) IOError for at least 2.4.x I would also appreciate comments in the fixed 2.4 code if it is going to change for 2.5. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-02-10 22:25 Message: Logged In: YES user_id=261020 Jim, I don't understand the first sentence in your comment. Re a 2.4 backport that makes LoadError derive from IOError: it makes me wince, but I can't think of an argument against it. No, LoadError should not be a subclass of IOError in the trunk, because the cases where LoadError is documented to be raised do not involve failures of I/O, but rather invalid data. See the docs for IOError. (FWIW, EnvironmentError (IOError's base class) wouldn't be a suitable subclass either: eg. what would we want with an .errno attribute?) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-02-08 16:58 Message: Logged In: YES user_id=764593 I often look at the code in a second idle window rather than starting a web browser. Would it work to make LoadError a subclass of IOError, at least for the backport? People who followed the docs will get a bugfix, but people who followed the code would get no breakage. Should LoadError be a subclass of IOError even in the main trunk? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1117398&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
