[Python-Dev] FileCookieJars

[Demian Brecht]

On 2013-03-10 1:59 PM, R. David Murray wrote:
> To be clear, just passing the stdlib tests is*not*  sufficient to think
> that backward compatibility is not likely to be broken.  Deciding about
> the likelihood of breakage is a hard problem, to which we generally
> employ gut-level heuristics:)  (And code search, as Steven suggests).

I figured that this would be a hard problem, which is also why I didn't 
delve into a patch further than a proposed first stab at a more sane 
implementation, coupled with changes to the unit tests.

> Since you say that it will "obviously" break backward compatibility, I'd
> say that if we are going to do anything we'd have to think about how best
> to introduce a more sane implementation and deprecate the old...and if we
> are going to do that, we probably ought to spend a bit of time seeing if
> there are any other open cookiejar issues we can tackle at the same time.

I was hoping that there would be a little more interest (and potentially 
some further historical context on why the module was implemented as it 
was) from those in the group.

> If, that is, you are interested enough to continue to be the point person
> for this, which probably won't be a short process:)

I'm not sure who this was directed to (me or Steven), but I was looking 
for an area in the stdlib that I could really sink my teeth into and get 
my hands dirty with and this definitely seems to be just that. I figured 
that it wouldn't be a short process and the more that I read up on RFC 
6265 (and 2965) and compare them to the implementation in cookie and 
cookiejar, the more I'm thinking that this will be a relatively complex 
and lengthy process. (Definitely interested in that btw :)).

>
> The problem here is getting people interested, apparently:(
>
> Since I start my Pycon diversion-from-work next week, maybe I can find
> some time to take at least a preliminary look.

In case you haven't already seen it, I had posted a second patch (that 
doesn't break the Liskov substitution principle as Terry pointed out 
after reviewing my overzealous initial patch) here: 
http://bugs.python.org/issue16901. I think the design is much more sane 
than what's currently there and aligns with how HTTP cookies are 
processed in urllib.request.

Now having said all that, the more I think about it and the more I read, 
the more I wonder why there are even specialized implementations (LWP 
and Mozilla) in the stdlib to begin with. I would assume that the only 
thing that the stdlib /should/ be covering is the RFC (6265, but still 
allowing 2965).

If there are deviations (and some are eluded to throughout the code), 
then I would think that those should be handled by packages external to 
the stdlib. It seems that the Mozilla implementation covers 2965, but 
LWP is based on the Perl library (which isn't known to be supported by 
any browser environment). Why is this even there to begin with? To 
paraphrase the comments that I read in the code: "This isn't supported 
by any browser, but they're easy to parse". In my mind, this shouldn't 
be reason enough for inclusion in the stdlib.

I'd also go as far to say that if cookies are implemented as 
consistently as, say, OAuth 2.0 providers (meaning very little to no 
consistency), then there really shouldn't be a cookie implementation in 
the stdlib anyway.

So to sum it up, yes I'm very much interested in doing what I can to 
help the development of the stdlib (more so interested in parts that 
don't currently have experts listed, such as http and imaplib), but will 
definitely need to be shown the ropes a bit as my professional life has 
revolved around closed source games.