On 1/9/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > OK, let me repeat myself. >
OK. > I see no point in grouping modules just because they're servers. > That's fine. But they do server a similar purpose and so it is a legit suggestion. If no one else likes it then it won't go anywhere. I will take this as a -1 on any server-specific grouping. > I'd suggest a Web module containing: > > html: > htmlentitydefs > htmllib > HTMLParser > sgmllib (?) > > server: > > BaseHTTPServer > cgi > CGIHTTPServer > Cookie > wsgiref > > client: > > cookielib > httplib > urllib, urllib2, urlparse > > browser: (or these could just be part of "client") > > webbrowser > I already have that package but without the subpackging which I am not going to do. As I said, I am not going to push for anything more than a shallow (i.e., one level deep) package introduction. > "cgitb" is generic functionality, and should be merged into "traceback". > > The classes in SimpleHTTPServer should be merged into BaseHTTPServer. > > "urllib" and "urllib2" should be merged. "urlparse" should be merged into > urllib. > > What's in SocketServer should be merged into "socket". > I am not dealing with any merging unless I have to. Perhaps I should make that a basic rule that I am not handling merges into a package and that can be done separately. > Perhaps "web" could be part of a higher-level "internet" package, > which would also include "email", and things like nntplib and > stringprep. > As I said, I am not going to try to make any package deep. -Brett _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
