Skip to content

In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work #61105

Closed
Closed
In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work#61105
Assignees
JelleZijlstra
Labels
docsDocumentation in the Doc dirstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

Description

@py-user
py-user
mannequin
opened on Jan 8, 2013
BPO 16901
Nosy @terryjreedy, @asvetlov, @py-user, @vadmium, @demianbrecht
Files
  • cookiejar_16901.patch
    		•

    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 = None
created_at = <Date 2013-01-08.23:37:01.871>
labels = ['type-bug', 'library', 'docs']
title = "In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work"
updated_at = <Date 2013-06-18.06:43:52.975>
user = 'https://github.com/py-user'

    bugs.python.org fields:

    activity = <Date 2013-06-18.06:43:52.975>
actor = 'martin.panter'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'Library (Lib)']
creation = <Date 2013-01-08.23:37:01.871>
creator = 'py.user'
dependencies = []
files = ['29275']
hgrepos = []
issue_num = 16901
keywords = ['patch']
message_count = 7.0
messages = ['179398', '179755', '183195', '183196', '183206', '183208', '183235']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'asvetlov', 'docs@python', 'py.user', 'martin.panter', 'demian.brecht']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue16901'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

    Activity

    1. py-user commented on Jan 8, 2013

      @py-user
      py-usermannequin
      on Jan 8, 2013
      MannequinAuthor
      >>> 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'
>>>
    2. py-user
      added
      stdlibStandard Library Python modules in the Lib/ directory
      type-bugAn unexpected behavior, bug, or error
      on Jan 8, 2013

    3. terryjreedy commented on Jan 12, 2013

      @terryjreedy
      terryjreedy
      on Jan 12, 2013
      Member

      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.

    4. terryjreedy
      added
      docsDocumentation in the Doc dir
      on Jan 12, 2013
    5. terryjreedy
      assigned
      docspython
      on Jan 12, 2013

    6. demianbrecht commented on Feb 28, 2013

      @demianbrecht
      demianbrechtmannequin
      on Feb 28, 2013
      Mannequin

      (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.

    7. terryjreedy commented on Feb 28, 2013

      @terryjreedy
      terryjreedy
      on Feb 28, 2013
      Member

      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.

    8. py-user commented on Feb 28, 2013

      @py-user
      py-usermannequin
      on Feb 28, 2013
      MannequinAuthor

      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)

    9. demianbrecht commented on Feb 28, 2013

      @demianbrecht
      demianbrechtmannequin
      on Feb 28, 2013
      Mannequin

      @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.

    10. py-user commented on Feb 28, 2013

      @py-user
      py-usermannequin
      on Feb 28, 2013
      MannequinAuthor

      Demian Brecht:

      My proposal was made to python-ideas.

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

    11. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    12. serhiy-storchaka
      added this to Cookies issues 🍪on May 20, 2022
    13. JelleZijlstra
      self-assigned this
      on Oct 7, 2022
    14. JelleZijlstra
      added a commit that references this issue on Oct 7, 2022

      gh-61105: Add default param, note on using cookiejar subclass (#95427)

      5eaf4d6
    15. miss-islington
      added 4 commits that reference this issue on Oct 7, 2022

      pythongh-61105: Add default param, note on using cookiejar subclass (p…

      65998ce

      pythongh-61105: Add default param, note on using cookiejar subclass (p…

      dd46557

      gh-61105: Add default param, note on using cookiejar subclass (GH-95427)

      17c9ce1

      gh-61105: Add default param, note on using cookiejar subclass (GH-95427)

      1a31799
    16. slateny
      closed this as completedon Oct 8, 2022
    17. slateny
      moved this to Done in Cookies issues 🍪on Oct 8, 2022
    18. carljm
      added a commit that references this issue on Oct 8, 2022

      Merge branch 'main' into typewatch

      27a4980
    19. mpage
      added a commit that references this issue on Oct 11, 2022

      pythongh-61105: Add default param, note on using cookiejar subclass (p…

      864f9b9
    20. pablogsal
      added a commit that references this issue on Oct 22, 2022

      gh-61105: Add default param, note on using cookiejar subclass (GH-95427)

      e32c736
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    docsDocumentation in the Doc dirstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions