[stdlib-sig] Suggested tweaks to http and xmlrpc packages

[Brett Cannon]

On Feb 4, 2008 1:03 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> On Feb 4, 2008 2:38 PM, Brett Cannon <brett at python.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?

-Brett