Re: [Web-SIG] reorg of web-related modules for Python 3K
Bill Janssen wrote: > Over on the stdlib-sig, Brett's proposing that we move some of the > HTTP-related classes: > >> 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 I think WSGI is a better interface than any of these. BaseHTTPServer is a reasonable basis for building a server (wsgiref.simple_server and other's use it), but the subclasses are a little funky IMHO. Giving them the name http.server makes them seem like the Right Solution, and I don't think they are. They're more like server-building tools. >> cookielib -> http.cookies >> >> Since the various HTTP server modules have no name clashes we >> can consolidate them into a single module. > > Seems reasonable to me, but I thought it should be looked at in this > forum. All this is going into PEP 3108, so either join the stdlib-sig, > or read the PEP, if you care about all this. > > Alexandre Vassalotti further proposes the following: > >> xmlrpclib -> xmlrpc.tools >> SimpleXMLRPCServer -> xmlrpc.server >> DocXMLRPCServer -> xmlrpc.server Similarly here I think there are better ways to arrange servers than these subclasses -- both more reusable and simpler. Ian ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] more work on httplib?
> utility routines for client-side form manipulation: > encode_multipart_formdata, http_post_multipart, https_post_multipart I should point out that these are elaborations of Wade Leftwich's Python Cookbook recipes. > cookie readers for Firefox and Safari cookie file formats I'm still restricting myself to Python 2.3, so I haven't really looked at cookielib. Bill ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] more work on httplib?
I've been working on a personal digital library server, written in Python, built on top of Medusa, now in beta test at http://uplib.parc.com/. We're releasing it under the GPLv2 (actually, have already released it to our beta testers -- if you'd like to join the fun, just create an account on the blog). As part of the system, I had to write a number of extensions to the core library's HTTP and HTML support, including versions of httplib.HTTP and HTTPSConnection that verify the server's certificates htmlescape(), a version of cgi.escape() that quotes HTML correctly utility routines for client-side form manipulation: encode_multipart_formdata, http_post_multipart, https_post_multipart a list of defined HTTP status codes, by name a version of urllib.urlretrieve() that handles cookies, proxies, and redirects (I think this could be written as a urllib2 Opener) cookie readers for Firefox and Safari cookie file formats a web site caching function that fetches all ancillary material (CSS, ECMAscript, images, etc) and links it in properly, essentially creating what Mozilla calls a "Web Page Complete" version Not to mention the new SSL module. I found it irritating that I had to write all of this myself, instead of just pulling it from the standard library. Now that it's released, what's already in the standard library (that I just didn't know about :-)? And which items should I file bug reports on? Bill ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] reorg of web-related modules for Python 3K
Over on the stdlib-sig, Brett's proposing that we move some of the HTTP-related classes: > 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. Seems reasonable to me, but I thought it should be looked at in this forum. All this is going into PEP 3108, so either join the stdlib-sig, or read the PEP, if you care about all this. Alexandre Vassalotti further proposes the following: > xmlrpclib -> xmlrpc.tools > SimpleXMLRPCServer -> xmlrpc.server > DocXMLRPCServer -> xmlrpc.server Personally, I'd put those under "http.", or maybe "http.xmlrpc.". Bill ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Removal of Cookie in Python 3.0 OK?
web2py uses it cookie too but probably it would not take much to port it to cookielib. It would be great if you could provide an example of usage of cookielib.Cookie vs cookie.SimpleCookie. In particular, I cannot find any example of how to serialize a cookielib.Cookie into the corresponding http header entry. Massimo On Feb 3, 2008, at 5:58 PM, René Dudfield wrote: > Here's some usages of Cookie that show quite wide use still: > http://www.google.com/codesearch?q=lang%3Apython+%22import+Cookie%22 > >> From the first few pages: mailman, zope, trac, roundup, cherrypy, > chandler, turbogears, myghty, paste, moin, mod_python etc. > > Not that that's the only reason why you wouldn't remove it... just > backing up Ians assertion that Lots of web frameworks use it. > > cu. > > > On Feb 4, 2008 10:41 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: >> Brett Cannon wrote: >>> As part of the standard library cleanup for Python 3.0, it has been >>> suggested to me that the Cookie module be removed. The rationale for >>> this is that most of the module is already deprecated and cookielib >>> does a better job for cookie support anyway. >>> >>> I just wanted to see if anyone here had strong objections (along >>> with >>> reasons) as to why the module should be kept around in some form or >>> another. >> >> I think most frameworks still use the Cookie module. The cookielib >> module is more oriented to the client side. It doesn't seem to >> have the >> same parsing functions that you'd use on the server side (though >> maybe >> they are there and just not documented because they also exist in the >> Cookie module). >> >>Ian >> >> ___ >> Web-SIG mailing list >> Web-SIG@python.org >> Web SIG: http://www.python.org/sigs/web-sig >> Unsubscribe: http://mail.python.org/mailman/options/web-sig/renesd% >> 40gmail.com >> > ___ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/ > mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Removal of Cookie in Python 3.0 OK?
Here's some usages of Cookie that show quite wide use still: http://www.google.com/codesearch?q=lang%3Apython+%22import+Cookie%22 >From the first few pages: mailman, zope, trac, roundup, cherrypy, chandler, turbogears, myghty, paste, moin, mod_python etc. Not that that's the only reason why you wouldn't remove it... just backing up Ians assertion that Lots of web frameworks use it. cu. On Feb 4, 2008 10:41 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > As part of the standard library cleanup for Python 3.0, it has been > > suggested to me that the Cookie module be removed. The rationale for > > this is that most of the module is already deprecated and cookielib > > does a better job for cookie support anyway. > > > > I just wanted to see if anyone here had strong objections (along with > > reasons) as to why the module should be kept around in some form or > > another. > > I think most frameworks still use the Cookie module. The cookielib > module is more oriented to the client side. It doesn't seem to have the > same parsing functions that you'd use on the server side (though maybe > they are there and just not documented because they also exist in the > Cookie module). > >Ian > > ___ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/renesd%40gmail.com > ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Removal of Cookie in Python 3.0 OK?
Brett Cannon wrote: > As part of the standard library cleanup for Python 3.0, it has been > suggested to me that the Cookie module be removed. The rationale for > this is that most of the module is already deprecated and cookielib > does a better job for cookie support anyway. > > I just wanted to see if anyone here had strong objections (along with > reasons) as to why the module should be kept around in some form or > another. I think most frameworks still use the Cookie module. The cookielib module is more oriented to the client side. It doesn't seem to have the same parsing functions that you'd use on the server side (though maybe they are there and just not documented because they also exist in the Cookie module). Ian ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Removal of Cookie in Python 3.0 OK?
As part of the standard library cleanup for Python 3.0, it has been suggested to me that the Cookie module be removed. The rationale for this is that most of the module is already deprecated and cookielib does a better job for cookie support anyway. I just wanted to see if anyone here had strong objections (along with reasons) as to why the module should be kept around in some form or another. -Brett ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
