On Feb 4, 2008 1:03 PM, Alexandre Vassalotti email@example.com wrote:
On Feb 4, 2008 2:38 PM, Brett Cannon firstname.lastname@example.org wrote:
So the suggestions now are:
httplib ->http.client http.server proposal stays.
xmlrpclib -> xmlrpc.client xmlrpc.server proposal stays.
`xmlrpclib` also contains (un)marshaling tools, so it's not strictly a client library. Anyway, I like the "client" subpackage name more than "tools."
There is also the issue of the cookie-related modules. Ignoring singular vs. plural, we have Cookie and cookielib. Having looked at them I don't think they can be reasonably merged into a single module with their naming the way they are. And on the web-sig they said that Cookie is still widely used. So http.cookie(s) might not be able to happen without reworking cookielib to gain the abilities Cookie has in some reasonable fashion.
Well, I never used either cookie modules, so I can't really comment about them. However, I found by reading through the documentation and the code that both modules have a fairly different purpose. `cookielib` is used for collecting cookies on the client-side (often with urllib2), while `Cookie` is used to generate cookie on the server-side.
That is what I am starting to realize. If I had my way I would want to rename them:
cookielib -> cookie.client Cookie -> cookie.server
But that does not exactly follow Guido's shorter name desire. But considering Cookie breaks the naming scheme as it is and thus will have to be renamed and cookie is rather generic, we might be able to get away with this renaming. What do people think?