[Web-SIG] Merge Cookie and cookielib?

[Brett Cannon]

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.

Merging them into a single cookie module blindly (as is happening with
the various *HTTPServer modules) is not reasonable, though. Cookie has
two classes names BaseCookie and SimpleCookie. cookielib has a class
named Cookie. Cookie's classes have nothing to do with the classes
exposed by cookielib. But obviously the names are similar enough to
probably cause confusion for new users.

Unfortunately 2to3 can't handle the renaming of a class from an
imported module accurately like it can for imports since it works on a
line-by-line basis. Fred Drake has suggested merging the two modules
and renaming the stuff in the modules as needed. I'm fine with that,
but that is beyond my role as the man with the big stick for the
stdlib reorg.

So my question is whether you all would be up for handling a merging
of Cookie and cookielib for 2.6? I have no issue if you all want to
take it as far as to deprecate both modules and come up with a new one
that becomes http.cookie since that would probably be a
PendingDeprecationWarning on the two modules and that won't impact
Python 3.0 since all warnings must be dealt with to transition cleanly
from 2.x to 3.0. Or if you just want to rename the classes that is
fine by me as well. Either way this would be a 2.6 change that just
happened to lead to 3.0 having only a single cookie-related module in
the http package.

-Brett