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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
