"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
