Mailman 3 - stdlib-sig

Re: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
by Brett Cannon 04 Feb '08

04 Feb '08

On Feb 3, 2008 9:06 PM, Bill Janssen <janssen(a)parc.com> wrote: > I'm good with the proposed HTTP re-org, but I think the XML-RPC > classes should also go into the "http." package (http.tools or > http.server as appropriate) -- there's nothing magical about XML-RPC. > Well, it's an RPC protocol, not something specific to HTTP. It might use HTTP as its transport agent, but that's its only connection. When I think "XML-RPC", I don't automatically think, "I should look in the HTTP section of the standard library". I think either XML-RPC or RPC protocols. > Maybe a subpackage, "http.xmlrpc". > Problem with that is Guido said he wants any renaming to make the name as simple if not simpler. Sticking XML-RPC libraries into http does not do that. Plus there is a general agreement that these new packages will only be one level deep. > I also think putting server classes into "http.server", but putting > the client-side code, httplib, into "http.tools", is a bit lopsided. > True, httplib is a mix of client-side and general utility functions, > but still... But that's a minor nit. On the other hand, if we're > going to mess around with the locations, might as well get it right > the first time. > Sure, but what is right? The reason it has taken this long and led to the creation of a separate mailing list is because everyone's "right" is different. We are going to end up with a better solution, but there is not right solution. -Brett

2 1

http package proposal
by Brett Cannon 04 Feb '08

04 Feb '08

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

5 6

Any feedback on proposed http and xmlrpc packages?
by Kevin Teague 04 Feb '08

04 Feb '08

I would prefer xmlrpc.client over xmlrpc.tools and http.client over http.tools. The documentation and comments for these modules refer to them as client libraries. They do have some bits that could be used as tools, but I would guess that the vast majority of uses are as clients. The examples and test suites in these modules also only deals with the client use case, they don't test or demonstrate the tools portion of the code. -1 on http.xmlrpc.client. Yes, XML-RPC uses HTTP as a transport, but then HTTP uses TCP/IP as a transport, which would suggest socket.http.xmlrpc or tcpip.http.xmlrpc. HTTP is an implementation detail of XML-RPC. I've trained a number of bioinformaticians to use XML-RPC and for better or worse they are usually oblivious to HTTP. They can usually solve their XML-RPC needs with the abstraction of "XML-RPC communicates over the network to talk to remote servers" without needing to know any specifics about HTTP. http://docs.python.org/lib/module-xmlrpclib.html "XML-RPC client access" xmlrpclib.py: # # $Id: xmlrpclib.py 38463 2005-02-11 18:00:16Z fdrake $ # # an XML-RPC client interface for Python. # # the marshalling and response parser code can also be used to # implement XML-RPC servers. # http://docs.python.org/lib/module-httplib.html "HTTP protocol client" httplib.py: """HTTP/1.1 client library

2 1

Any feedback on proposed http and xmlrpc packages?
by Brett Cannon 04 Feb '08

04 Feb '08

I just wanted to make sure no one had any issues with the proposed http or xmlrpc packages before I add them to PEP 3108. -Brett

4 5

Re: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
by Brett Cannon 03 Feb '08

03 Feb '08

On Feb 3, 2008 3:07 PM, Bill Janssen <janssen(a)parc.com> wrote: > > > I just wanted to make sure no one had any issues with the proposed > > > http or xmlrpc packages before I add them to PEP 3108. > > > > For what it's worth, I like the proposed scheme. > > For what it's worth, I just joined this list. What does the Web-SIG > think about them? You might want to post the scheme there for more > feedback. You can if you want, Bill, but I don't want our process getting tied into other groups. Besides, this is just renaming, not the removal of any code. I honestly don't see it as part of their domain. -Brett

1 0

xml-rpc package proposal (was: http package proposal)
by Brett Cannon 30 Jan '08

30 Jan '08

On Jan 29, 2008 5:20 PM, Alexandre Vassalotti <alexandre(a)peadrop.com> wrote: > 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 I had not gotten that far (just doing them as I find time to bother to think about and send an email), but I like your proposal. What do others think? -Brett

2 1

PEP 3108
by M.-A. Lemburg 22 Jan '08

22 Jan '08

Hi all, just skimmed through PEP 3108. A few comments: * The renaming is done inconsistently, e.g. "simple_http_server", "simple_xmlrpc_server", but "socketserver" There should either always be an underscore to separate words, or none. I don't think that underscores in module names are particularly nice, so I'd opt for going with the no-underscores versions. * dbm renaming is going to cause trouble The reason is that there already is a dbm module with a defined interface which the package is likely not going to provide. I also don't think that "dbm" meaning database manager is really what the modules are all about. They usually just implement on-disk dictionaries, nothing more complicated. A DBM usually has a bit more to offer, e.g. think Oracle :-) All in all, I'm not sure whether this is worth the trouble. sqlite is a far better choice than any of the dbm-style modules, IMHO, and it provides an upgrade path to more sophisticated RDBMs. * "All database related modules will be moved to a database package. These modules include: bsddb, dbm, gdbm, sqlite, anydbm, dbhash, dumbdbm, whichdb." Does this refer to the proposed "dbm" package or is there going to be a new "database" package ? Please be careful not to introduce *new* generic and widely used names for stdlib modules or packages or alternatively, go for the stdlib-in-a-package approach to work around any such issues (this is what I did for the mx packages when it became obvious that DateTime was an overly generic package name). * Integrating the C performance boost modules into the Python versions Most of the C extensions do not implement the complete set of APIs that are available in the Python version, or they work differently / do not allow sub-classing. Eg. if you want to write an extended pickle mechanism, you can do so by subclassing from the Python version, but not from the cPickle version. Ideal would be to rewrite the C code to work like the Python code (or vice-versa), but this seems outside the scope of the PEP. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 22 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611

5 10

Added dbm package to PEP 3108
by Brett Cannon 21 Jan '08

21 Jan '08

So the dbm package as discussed on the old list has now been added to PEP 3108. I also updated the spreadsheet. I went with 'dbm.tools' as I liked Steve's arguments for it plus I just plain prefer it. =) I expect we will tackle the http package next when I (or someone else) starts off an email with suggested names (I have some already in the spreadsheet, but I should be doing real work instead of this =). -Brett

1 0