[Python-Dev] FileCookieJars

[Demian Brecht]

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