>>> import http.cookiejar
>>> cjf = http.cookiejar.FileCookieJar()
>>> cjf.load('file.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load
    self._really_load(f, filename, ignore_discard, ignore_expires)
AttributeError: 'FileCookieJar' object has no attribute '_really_load'
>>> 
>>> 
>>> import http.cookiejar
>>> cjf = http.cookiejar.FileCookieJar('file.txt')
>>> cjf.load()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load
    self._really_load(f, filename, ignore_discard, ignore_expires)
AttributeError: 'FileCookieJar' object has no attribute '_really_load'
>>>
>>> 
>>> cjf.revert()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1789, in revert
    self.load(filename, ignore_discard, ignore_expires)
  File "/usr/local/lib/python3.3/http/cookiejar.py", line 1767, in load
    self._really_load(f, filename, ignore_discard, ignore_expires)
AttributeError: 'FileCookieJar' object has no attribute '_really_load'
>>>

First, a minor issue about class signatures:
doc: FileCookieJar(filename, delayload=None, policy=None)
code: def __init__(self, filename=None, delayload=False, policy=None)
Pretty clearly, doc should be changed to match code, as later code allow for possibility of filename = None (meaning that that is intentional).

Ditto for doc for FileCookieJar subclasses (which inherit __init__):
MozillaCookieJar(filename, delayload=None, policy=None) 
LWPCookieJar(filename, delayload=None, policy=None)

--- 
FileCookieJar has .load which in inherited by the subclasses. It checks for a filename and opens it and then calls ._really_load. The two subclasses have customized ._really_load methods that correspond to their customized .save methods.

FileCookieJar itself does not. If it did, it would have to somehow be 'generic'. This suggests to me that FileCookieJar was not intended to be directly used. This impression is reinforced by the definition of .save().

    def save(self, filename=None, ignore_discard=False, ignore_expires=False):
        """Save cookies to a file."""
        raise NotImplementedError()

In other words, there is no generic format to save to *or* load from.
There should be a corresponding ._really_load to raise the same exception.

Bottom line: as best I understand, your code is not intended to work, but both the doc and implementation are deficient in not saying so, and both should be improved.

(Note: Additional context can be found here: http://bugs.python.org/issue16942, which seems to be a dupe of this report)

I haven't had any feedback to my proposal on python-ideas about the removal of LWPCookieJar and MozillaCookieJar and the introduction of LWPCookieProcessor and MozillaCookieProcessor yet (http://thread.gmane.org/gmane.comp.python.ideas/19673), which could be indicative of this change simply not being acceptable. However, on the outside chance that's not the case, I've submitted a patch covering the proposed implementations. All tests pass. 

The patch addresses some of the oddities around FileCookieJar looking, but not behaving as an abstract class as well as inheriting from a concrete class (CookieJar). The change aligns LWPCookies and MozillaCookies with the HTTPCookies. This should fix the questions around why FileCookieJar can't be used directly. If this change looks reasonable, corresponding documentation changes will be made as well.

Note: This change /does/ break backwards compatibility. I'm not sure what the process is for that, so if this change is eventually applied, pointers as to what should be integrated where would be helpful.

I suspect most people don't use or care much about cookies and cookie jar and do not understand the issue of proposal enough to comment. My feeling is that the patch probably breaks more than is necessary to fix the immediate problem and too much for current releases. For one, just the name change seems unnecessary. I need to look at HTTPCookies before I can say more.

Demian Brecht wrote:
>I haven't had any feedback to my proposal on python-ideas about the >removal of LWPCookieJar and MozillaCookieJar and the introduction of >LWPCookieProcessor and MozillaCookieProcessor yet >(http://thread.gmane.org/gmane.comp.python.ideas/19673), which could be >indicative of this change simply not being acceptable.

all python ideas are discussed in python lists (for users and for developers)

@Terry: I don't think that the name change is unnecessary as the patch changes the semantics of the the LWP and Mozilla Cookie classes. In the patch, they no longer /are/ a subclass of a CookieJar, but they take a CookieJar object and implement the FileCookieProcessor interface in order to save/load/revert file-based cookies.

This solves the problem of an abstract base class (or at least, what was /intended/ to be an abstract base class prior to abcs: FileCookieJar) extending a concrete class, which doesn't make sense from an architectural standpoint. It also fixes the problem that people are encountering when attempting to instantiate a FileCookieJar object, it doesn't just patch something that's fundamentally broken. It could be my lack of experience with large scale OSS, but I'd prefer a /correct/ fix (especially to something that few actually care about and is seemingly not in heavy use) over a duct taped "just make it work" solution.

I absolutely agree, however, that this is a rather large change (as far as the cookiejar module goes anyway) and shouldn't be taken lightly. However, the cookiejar module /is/ in need of some love and I think that this takes a step to giving it that.

@py.user: My proposal was made to python-ideas. I just prefer gmane to Google Group for links.

Demian Brecht:
>My proposal was made to python-ideas.

try this
http://mail.python.org/mailman/listinfo/python-dev