[Python-Dev] FileCookieJars (original) (raw)

Demian Brecht demianbrecht at gmail.com
Fri Mar 1 16:43:06 CET 2013

Cross-posting from python-ideas due to no response there. Perhaps it's due to a general lack of usage/caring for cookiejar, but figured /someone/'s got to have an opinion about my proposal ;)

Note that I've moved my discussion from bug 16942 to 16901 (http://bugs.python.org/issue16901) as they're duplicates and 16901 is more succinct. I've also posted a patch in 16901 implementing my proposal.

TL;DR: CookieJar > FileCookieJar > *CookieJar are architecturally broken and this is an attempt to rectify that (and fix a couple bugs along the way).

Context: http://bugs.python.org/issue16942 (my patch, changing FileCookieJar to be an abc, defining the interfaces for *FileCookieJar).

This pertains to Terry's question about whether or not it makes sense that an abstract base class extends a concrete class. After putting in a little thought, he's right. It doesn't make sense.

After further thought, I'm relatively confident that the hierarchy as it stands should be changed. Currently what's implemented in the stdlib looks like this:

CookieJar |FileCookieJar | | | MozillaCookieJar LWPCookieJar

What I'm proposing is that the structure is broken to be the following:

FileCookieJarProcessor CookieJar | | | MozillaCookieJarProcessor LWPCookieJarProcessor

The intention here is to have processors that operate /on/ a cookiejar object via composition rather than inheritance. This aligns with how urllib.request.HTTPCookieProcessor works (which has the added bonus of cross-module consistency).

The only attributes that concrete FileCookieJarProcessor classes touch (at least, in the stdlib) are _cookies and _cookies_lock. I have mixed feelings about whether these should continue to be noted as "non-public" with the _ prefix or not as keeping the _ would break convention of operating on non-public fields, but am unsure of the ramifications of changing them to public.

Making this change then allows for FileCookieJar(Processor) to be an abstract base class without inheriting from CookieJar which doesn't make a whole lot of sense from an architecture standpoint.

I have yet to see what impact these changes have to the cookiejar extensions at http://wwwsearch.sf.net but plan on doing so if this approach seems sound.

This will obviously break backwards compatibility, so I'm not entirely sure what best practice is around that: leave well enough alone even though it might not make sense, keep the old implementations around and deprecate them to be eventually replaced by the processors, or other ideas?

-- Demian Brecht http://demianbrecht.github.com

More information about the Python-Dev mailing list