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 _______________________________________________ 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