http package proposal
OK, to keep this ball rolling, here is my suggestion for reorganizing HTTP modules:
httplib -> http.tools BaseHTTPServer -> http.server SimpleHTTPServer -> http.server CGIHTTPServer -> http.server cookielib -> http.cookies
Since the various HTTP server modules have no name clashes we can consolidate them into a single module.
-Brett
Sounds good. Is there any plan to do a similar packaging with the xmlrpc-related modules? For example,
xmlrpclib -> xmlrpc.tools SimpleXMLRPCServer -> xmlrpc.server DocXMLRPCServer -> xmlrpc.server
-- Alexandre
On Jan 29, 2008 6:38 PM, Brett Cannon brett@python.org wrote:
OK, to keep this ball rolling, here is my suggestion for reorganizing HTTP modules:
httplib -> http.tools BaseHTTPServer -> http.server SimpleHTTPServer -> http.server CGIHTTPServer -> http.server cookielib -> http.cookies
Since the various HTTP server modules have no name clashes we can consolidate them into a single module.
On 2008-01-30 00:38, Brett Cannon wrote:
OK, to keep this ball rolling, here is my suggestion for reorganizing HTTP modules:
httplib -> http.tools
httplib implements the state machine for an HTTP client, so why not http.client ?
BaseHTTPServer -> http.server SimpleHTTPServer -> http.server CGIHTTPServer -> http.server
cookielib -> http.cookies
Why plural ?
-1 on adding xmlrpc to the http package.
Better to have:
xmlrpclib -> xmlrpc.client SimpleXMLRPCServer -> xmlrpc.server
M.-A. Lemburg wrote:
cookielib -> http.cookies
Why plural ?
The plural form feels more natural to me. I haven't seen the singular form "browser cookie" in a long time.
-1 on adding xmlrpc to the http package.
Better to have:
xmlrpclib -> xmlrpc.client SimpleXMLRPCServer -> xmlrpc.server
+1 for xmlrpc package.
Christian
On 2008-02-04 16:02, Christian Heimes wrote:
M.-A. Lemburg wrote:
cookielib -> http.cookies
Why plural ?
The plural form feels more natural to me. I haven't seen the singular form "browser cookie" in a long time.
It's actually more about convention than actual use :-)
If we name the module http.cookies, we'd also have to name the server module http.servers, since there are multiple server implementations included.
However, you normally don't do this in code libraries (see e.g Java).
-1 on adding xmlrpc to the http package.
Better to have:
xmlrpclib -> xmlrpc.client SimpleXMLRPCServer -> xmlrpc.server
+1 for xmlrpc package.
It's actually more about convention than actual use :-)
If we name the module http.cookies, we'd also have to name the server module http.servers, since there are multiple server implementations included.
http.cookies is about managing cookies, i.e. you often manage several cookies at a time. On the other hand you seldom launch several HTTP servers in the same program. The difference looks natural to me.
On 2008-02-04 16:38, Antoine wrote:
It's actually more about convention than actual use :-)
If we name the module http.cookies, we'd also have to name the server module http.servers, since there are multiple server implementations included.
http.cookies is about managing cookies, i.e. you often manage several cookies at a time. On the other hand you seldom launch several HTTP servers in the same program. The difference looks natural to me.
Like I said: it's a matter of convention.
There are other instances in the stdlib where one or the other style is used, e.g. codecs, types, pipes, collestions vs. re, decimal, datetime, Queue.
While we're at it, we could cleanup those as well and stick with one naming scheme.
I don't have a clear favorite, except that other language libraries use the singular form throughout.
Perhaps all that's needed is a spelled-out more complex convention which makes it clear why http.server uses the singular form, while http.cookies is plural.
Another nit: some modules are named ...lib, while others do not include this suffix. It's not quite clear why a modules that's already part of the standard lib needs to have the "...lib" suffix. This is also not handled in a consistent manner, e.g. hashlib, ftplib, htmllib vs. xml, subprocess, shelve.
I'd be in favor of dropping the "lib" suffixes.
participants (5)
-
Alexandre Vassalotti -
Antoine -
Brett Cannon -
Christian Heimes -
M.-A. Lemburg