Purpose of delayload in cookielib.FileCookieJar?

0 views
Skip to first unread message

rre...@gmail.com

unread,
Jul 9, 2007, 8:36:47 PM7/9/07
to
What is the reason for delayload=False in the FileCookieJar.__init__
function? It doesn't seem to be used in any of the code that ships
with python2.4, and it seems to directly contradict the comment
following it

"""
Cookies are NOT loaded from the named file until either
the .load() or
.revert() method is called.

"""

which sounds like exactly the opposite the delayload=False default.

John J. Lee

unread,
Jul 10, 2007, 7:00:31 PM7/10/07
to
"rre...@gmail.com" <rre...@gmail.com> writes:

> What is the reason for delayload=False in the FileCookieJar.__init__
> function? It doesn't seem to be used in any of the code that ships
> with python2.4,

That is true, as is in fact explicitly documented:

http://docs.python.org/lib/cookie-jar-objects.html

"""
delayload
If true, load cookies lazily from disk. This attribute should not
be assigned to. This is only a hint, since this only affects
performance, not behaviour (unless the cookies on disk are
changing). A CookieJar object may ignore it. None of the
FileCookieJar classes included in the standard library lazily
loads cookies.
"""

Of the CookieJar implementations I know of (i.e. the ones I wrote),
only MSIECookieJar takes notice of .delayload . That class is not
included with the stdlib.


> and it seems to directly contradict the comment
> following it
>

> """
> Cookies are NOT loaded from the named file until either
> the .load() or
> .revert() method is called.
>
> """
>
> which sounds like exactly the opposite the delayload=False default.

The .load() and .revert() methods do cause the cookies to be loaded:
if you don't call one of them, the CookieJar won't see the cookies; if
you do call one of them, the CookieJar will see them (but see below re
iteration). .delayload simply changes the way that loading is
implemented.

The reason for delayload's existence is that MSIE stores cookies in
such a way (one cookie per file, or something; I forget now) that
loading all of them at once can be slow. So MSIECookieJar only
*actually* loads those it needs to keep the server happy -- but code
using that cookie jar doesn't need to know that; as far as it's
concerned, those cookies are loaded, and that's that. One
sort-of-exception: Note this extract from the MSIECookieJar docstring:

"""
Iterating over a delayloaded MSIECookieJar instance will not cause
any cookies to be read from disk. To force reading of all cookies
from disk, call read_all_cookies. Note that the following methods
iterate over self: clear_temporary_cookies, clear_expired_cookies,
__len__, __repr__, __str__ and as_string.
"""

It's quite rare to care about that, since usually you'll just be
passing the CookieJar instance to urllib2.HTTPCookieProcessor or
similar, in order to send and receive cookies over HTTP, which does
not require iteration over all cookies. Adding an explicit note about
iteration to the docs for .delayload would be good, though. Perhaps
I'll file a patch.

The other exception of course is that .delayload determines whether
you'll see updates to cookies that change between the .load() /
.revert() call and the time the CookieJar actually decides to read the
relevant file (this is already explicitly pointed out in the docs).


John

Reply all
Reply to author
Forward
0 new messages