[Web-SIG] Cookie, cookielib; what to do?

Brett Cannon brett at python.org
Fri Feb 29 02:24:26 CET 2008


When I brought this up last it was when I first began bombarding this
list with stdlib reorganization questions, so there was some noise
about the whole process and no clear resolution was reached.

The problem is that both modules have a Cookie class, so they can be
merged. Much like the url* issue, one option is keeping both, although
no great names came up. The whole cookie.client cookie.server didn't
seem to win people over. Maybe cookie.client and cookie.parsing?

The other option is to drop Cookie for cookielib, but people didn't
seem to love that idea, so I am not pushing hard for that as their
uses don't overlap very well (if I am wrong, please correct me). And I
am not willing to count on a merger of functionality into cookielib in
time for 3.0's release.

So my question is what do people see as a possible naming scheme for
these modules? Cookie has to be renamed because of its PEP 8
violation.  Here are some ideas::

 cookielib -> cookielib
 Cookie -> cookielib2 (with plans to move what needs to go from Cookie
into cookielib at some point and to deprecate cookielib2 in 3.x).

  cookielib -> http.cookies
  Cookie -> http.cookies2 (same thinking as above).

  cookielib -> cookies.client
  Cookie -> cookies.parsing

Any input on this would be great.


More information about the Web-SIG mailing list