Suggested tweaks to http and xmlrpc packages
So the suggestion has come up in a couple separate emails (I know MAL and Kevin at least, maybe even Bill) to do some tweaks to the proposed http and xmlrpc packages. I want to start a separate email on that to more easily collect people's thoughts in a single place.
So the suggestions now are:
httplib ->http.client http.server proposal stays.
xmlrpclib -> xmlrpc.client xmlrpc.server proposal stays.
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.
-Brett
On Feb 4, 2008 2:38 PM, Brett Cannon brett@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.
-- Alexandre
On Feb 4, 2008 1:03 PM, Alexandre Vassalotti alexandre@peadrop.com wrote:
On Feb 4, 2008 2:38 PM, Brett Cannon brett@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
Le lundi 04 février 2008 à 13:12 -0800, Brett Cannon a écrit :
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?
It sounds a bit bizarre to me. There is no such thing as a "cookie server" or "cookie client". On the other hand "cookie.clientstorage" and "cookie.serverstorage" is certainly too long.
It is also strange that Cookie and cookielib do not seem to share any code (not even for parsing or encoding cookies).
On Feb 4, 2008 2:02 PM, Antoine Pitrou solipsis@pitrou.net wrote:
Le lundi 04 février 2008 à 13:12 -0800, Brett Cannon a écrit :
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?
It sounds a bit bizarre to me. There is no such thing as a "cookie server" or "cookie client". On the other hand "cookie.clientstorage" and "cookie.serverstorage" is certainly too long.
It is also strange that Cookie and cookielib do not seem to share any code (not even for parsing or encoding cookies).
Different authors and they were added at different times in Python's history. If we can expose what is needed to replace Cookie from cookielib we can probably work to toss Cookie in Py3K.
-Brett
On Feb 4, 2008 1:03 PM, Alexandre Vassalotti alexandre@peadrop.com wrote:
On Feb 4, 2008 2:38 PM, Brett Cannon brett@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."
Well, I went ahead and made the change in the PEP (since the renamings won't happen until Guido clears the PEP none of this is in stone, although I don't want to constantly change the PEP either).
-Brett
participants (3)
-
Alexandre Vassalotti -
Antoine Pitrou -
Brett Cannon