[Web-SIG] Merge Cookie and cookielib?

[Ian Bicking]

Brett Cannon wrote:
> Since Bill Janssen prodded me on to this list I might as well take
> advantage now and bug you all about how to deal with Cookie and
> cookielib in the stdlib reorg.
> 
> My current idea is the new names cookie.client and cookie.server for
> Cookie and cookielib, respectively. While this goes against the goal
> of making the new names easier to work with, Cookie has to be renamed
> because of its PEP 8 violation. And having cookie and cookielib in the
> stdlib will not help with differentiating between the two.

Somehow cookie.server doesn't seem right to me.  cookie.client is 
reasonable -- cookielib is really intended to work with clients and 
implementing a browser-style persistent cookie database.  The Cookie 
module, however, is more focused on just the parsing portions, which is 
largely symmetric between client and server.  That there is a 
Cookie.Cookie class and a cookielib.Cookie class is somewhat unfortunate.

cookielib.Cookie is actually a quite reasonable representation of 
cookies, more reasonable than Cookie.Cookie IMHO.  Unfortunately the 
parsing routine in cookielib appears to be in CookieJar.make_cookies.

If the parsing routines were separated from the jar stuff then cookielib 
(renamed or not) would probably be a usable replacement for Cookie, and 
instead of two stdlib modules those frameworks that didn't upgrade could 
ship their own Cookie module or depend on it.  Using cookielib for a 
server-side framework would require more than a change in import 
statements.  The Cookie module uses a weird dict-like pattern that is 
only really found in the Cookie module, like some historical artifact of 
lost Python patterns, so there's no real reason to keep that pattern 
except laziness.

I however am probably too lazy with respect to this to depend on for 
more than this summary.

   Ian