From chris at simplistix.co.uk Fri Feb 1 21:53:42 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 01 Feb 2008 20:53:42 +0000 Subject: [Web-SIG] loggers and wsgi In-Reply-To: <479097E2.3080008@libero.it> References: <475D2C39.2000409@simplistix.co.uk> <4766D6D5.6010403@libero.it> <20071217210700.45C543A40A4@sparrow.telecommunity.com> <47683279.9010008@libero.it> <476855F2.3080007@colorstudy.com> <88e286470712181736g24ba8b73i16dcfe1b3b256de6@mail.gmail.com> <476905DD.5060100@simplistix.co.uk> <4769262B.3050106@libero.it> <476ADADA.10809@simplistix.co.uk> <88e286470712201600k549c4c9dnc6248e404c302f52@mail.gmail.com> <000001c8436a$b54a02e0$0701a8c0@Junk> <20071221011247.EA0413A40AC@sparrow.telecommunity.com> <476BC7B4.3020603@simplistix.co.uk> <20071221163128.9FBB93A40A4@sparrow.telecommunity.com> <478B98C0.4060404@simplistix.co.uk> <20080114173108.DF9623A4077@sparrow.telecommunity.com> <478CBDBA.2000109@simplistix.co.uk> <20080115151630.371483A40AE@sparrow.telecommunity.com> <478E1D36.5010600@simplistix.co.uk> <478E210E.4010308@libero.it> <478F4641.20103@simplistix.co.uk> <478F4B20.5060707@libero.it> <47908145.1050408@simplistix.co.uk> <479097E2.3080008@libero.it> Message-ID: <47A386D6.2040003@simplistix.co.uk> Manlio Perillo wrote: > The interface of the python logging is: > log(level, msg[, *args[, **kwargs]]) > right? > > > The problem with this is that, as an example, Twisted logging system > does not knows about log levels. > > Moreover, the message formatting is not done by the logging system. Then, at the worst case, twisted's wsgi server can handle this sensibly and process whatever is passed to .log in such a way that it can go to its own logging. > Do you think that a WSGI application should not be able to use some > advanced features offered by a web server (for embedded WSGI applications)? logging isn't a particularly advanced feature from my perspective. > from sqlalchemy import engine > > db = None > > class application(environ, start_response): > global db > > if db is None: > # Setup the database connection > db = engine.create_engine(environ['database_uri'], echo_pool=???) > > > what should I use for echo_pool? I don't know what echo_pool is. > Of course I can not use environ['wsgi.errors'] If you *really* wanted that to go to the front-end wsgi servers log (I'd just log it to its own log...) then I'd write a proxy object that handed calls off to whatever the current wsgi environ is or bitch if one wasn't available. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From brett at python.org Mon Feb 4 00:19:56 2008 From: brett at python.org (Brett Cannon) Date: Sun, 3 Feb 2008 15:19:56 -0800 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? Message-ID: 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 From ianb at colorstudy.com Mon Feb 4 00:41:21 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Sun, 03 Feb 2008 17:41:21 -0600 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: References: Message-ID: <47A65121.1020703@colorstudy.com> 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 From renesd at gmail.com Mon Feb 4 00:58:51 2008 From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=) Date: Mon, 4 Feb 2008 10:58:51 +1100 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <47A65121.1020703@colorstudy.com> References: <47A65121.1020703@colorstudy.com> Message-ID: <64ddb72c0802031558m59cd2fb4mcf49268cd24dc4f3@mail.gmail.com> 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 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 at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/renesd%40gmail.com > From mdipierro at cs.depaul.edu Mon Feb 4 01:11:16 2008 From: mdipierro at cs.depaul.edu (Massimo Di Pierro) Date: Sun, 3 Feb 2008 18:11:16 -0600 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <64ddb72c0802031558m59cd2fb4mcf49268cd24dc4f3@mail.gmail.com> References: <47A65121.1020703@colorstudy.com> <64ddb72c0802031558m59cd2fb4mcf49268cd24dc4f3@mail.gmail.com> Message-ID: 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 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 at 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 at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/ > mdipierro%40cti.depaul.edu From janssen at parc.com Mon Feb 4 06:01:15 2008 From: janssen at parc.com (Bill Janssen) Date: Sun, 3 Feb 2008 21:01:15 PST Subject: [Web-SIG] reorg of web-related modules for Python 3K Message-ID: <08Feb3.210116pst."58696"@synergy1.parc.xerox.com> 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 From janssen at parc.com Mon Feb 4 06:27:12 2008 From: janssen at parc.com (Bill Janssen) Date: Sun, 3 Feb 2008 21:27:12 PST Subject: [Web-SIG] more work on httplib? Message-ID: <08Feb3.212716pst."58696"@synergy1.parc.xerox.com> 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 From janssen at parc.com Mon Feb 4 07:07:57 2008 From: janssen at parc.com (Bill Janssen) Date: Sun, 3 Feb 2008 22:07:57 PST Subject: [Web-SIG] more work on httplib? In-Reply-To: <08Feb3.212716pst."58696"@synergy1.parc.xerox.com> References: <08Feb3.212716pst."58696"@synergy1.parc.xerox.com> Message-ID: <08Feb3.220801pst."58696"@synergy1.parc.xerox.com> > 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 From ianb at colorstudy.com Mon Feb 4 07:43:39 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 04 Feb 2008 00:43:39 -0600 Subject: [Web-SIG] reorg of web-related modules for Python 3K In-Reply-To: <08Feb3.210116pst."58696"@synergy1.parc.xerox.com> References: <08Feb3.210116pst."58696"@synergy1.parc.xerox.com> Message-ID: <47A6B41B.2000405@colorstudy.com> 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 From jim at zope.com Mon Feb 4 14:58:32 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 4 Feb 2008 08:58:32 -0500 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <47A65121.1020703@colorstudy.com> References: <47A65121.1020703@colorstudy.com> Message-ID: On Feb 3, 2008, at 6:41 PM, Ian Bicking 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). I think most web frameworks use setuptools at this point. I'd rather get this as a distribution, rather than from the standard library. In fact, I'd prefer to see all web-development libraries distributed separate from the language in Python 3. Jim -- Jim Fulton Zope Corporation From janssen at parc.com Mon Feb 4 16:31:15 2008 From: janssen at parc.com (Bill Janssen) Date: Mon, 4 Feb 2008 07:31:15 PST Subject: [Web-SIG] reorg of web-related modules for Python 3K In-Reply-To: <47A6B41B.2000405@colorstudy.com> References: <08Feb3.210116pst."58696"@synergy1.parc.xerox.com> <47A6B41B.2000405@colorstudy.com> Message-ID: <08Feb4.073122pst."58696"@synergy1.parc.xerox.com> > 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. Yes, these classes are quite old, and have been updated only patchily over the years. I don't use them, either. But I guess the question is whether wsgiref.* is a better _implementation_ than any of these. We don't really have interfaces in Python. Bill From ianb at colorstudy.com Mon Feb 4 18:07:08 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 04 Feb 2008 11:07:08 -0600 Subject: [Web-SIG] reorg of web-related modules for Python 3K In-Reply-To: <08Feb4.073122pst."58696"@synergy1.parc.xerox.com> References: <08Feb3.210116pst."58696"@synergy1.parc.xerox.com> <47A6B41B.2000405@colorstudy.com> <08Feb4.073122pst."58696"@synergy1.parc.xerox.com> Message-ID: <47A7463C.3050209@colorstudy.com> Bill Janssen wrote: >> 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. > > Yes, these classes are quite old, and have been updated only patchily > over the years. I don't use them, either. But I guess the question > is whether wsgiref.* is a better _implementation_ than any of these. > We don't really have interfaces in Python. wsgiref.simple_server actually uses BaseHTTPServer, so the implementations are tied. wsgiref.simple_server is a much better API than BaseHTTPServer. Even then, wsgiref.simple_server isn't the only server based on BaseHTTPServer, so it's not without some use as an abstract base class for servers. It's just not a useful base class for applications. Ian From brett at python.org Mon Feb 4 20:28:01 2008 From: brett at python.org (Brett Cannon) Date: Mon, 4 Feb 2008 11:28:01 -0800 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <47A65121.1020703@colorstudy.com> References: <47A65121.1020703@colorstudy.com> Message-ID: On Feb 3, 2008 3:41 PM, Ian Bicking 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). I honestly don't know. This was just something that someone proposed and I figured I would quickly look into, especially since I am trying to create a single http.cookies module. But if both modules stick around that might not work out very well having BaseCookie, SimpleCookie, and Cookie all in the same module but doing very different things. -Brett From ianb at colorstudy.com Mon Feb 4 20:39:57 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 04 Feb 2008 13:39:57 -0600 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: References: <47A65121.1020703@colorstudy.com> Message-ID: <47A76A0D.9000308@colorstudy.com> Brett Cannon wrote: > On Feb 3, 2008 3:41 PM, Ian Bicking 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). > > I honestly don't know. This was just something that someone proposed > and I figured I would quickly look into, especially since I am trying > to create a single http.cookies module. But if both modules stick > around that might not work out very well having BaseCookie, > SimpleCookie, and Cookie all in the same module but doing very > different things. I'd actually would prefer simple parsing functions instead of the objects of the Cookie module. And the only thing I really like in the cookie module is BaseCookie; the other classes try to be clever and just manage to be distracting or annoying. If as Jim suggests the existing Cookie module was made into an installable package we could have backward compatibility in addition to a cleaner stdlib going forward. (Or we could leave cookies out of the stdlib, but this particular functionality doesn't bother me since it's fairly clear, at least now, how it should be implemented.) Ian From brett at python.org Mon Feb 4 21:35:00 2008 From: brett at python.org (Brett Cannon) Date: Mon, 4 Feb 2008 12:35:00 -0800 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <47A76A0D.9000308@colorstudy.com> References: <47A65121.1020703@colorstudy.com> <47A76A0D.9000308@colorstudy.com> Message-ID: On Feb 4, 2008 11:39 AM, Ian Bicking wrote: > > Brett Cannon wrote: > > On Feb 3, 2008 3:41 PM, Ian Bicking 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). > > > > I honestly don't know. This was just something that someone proposed > > and I figured I would quickly look into, especially since I am trying > > to create a single http.cookies module. But if both modules stick > > around that might not work out very well having BaseCookie, > > SimpleCookie, and Cookie all in the same module but doing very > > different things. > > I'd actually would prefer simple parsing functions instead of the > objects of the Cookie module. And the only thing I really like in the > cookie module is BaseCookie; the other classes try to be clever and just > manage to be distracting or annoying. > > If as Jim suggests the existing Cookie module was made into an > installable package we could have backward compatibility in addition to > a cleaner stdlib going forward. (Or we could leave cookies out of the > stdlib, but this particular functionality doesn't bother me since it's > fairly clear, at least now, how it should be implemented.) I have no issue pushing Cookie out into the world on its own if that is what this SIG agrees upon. Make my life simpler. -Brett From janssen at parc.com Mon Feb 4 21:50:15 2008 From: janssen at parc.com (Bill Janssen) Date: Mon, 4 Feb 2008 12:50:15 PST Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: References: <47A65121.1020703@colorstudy.com> Message-ID: <08Feb4.125024pst."58696"@synergy1.parc.xerox.com> > I think most web frameworks use setuptools at this point. I'd rather > get this as a distribution, rather than from the standard library. In > fact, I'd prefer to see all web-development libraries distributed > separate from the language in Python 3. Jim, you want to have most things separate, if I've read your recent posts to the dev and 3k lists correctly. Lean and mean Python distribution. I'd agree with you if we had the infrastructure for it, something which would function at least as well as apt-get does, pulling dependencies and doing platform and version checks automatically. But I don't think Python is anywhere near that level of infrastructure, and it's a bit of a stretch just to maintain the infrastructure that currently exists. Given that, I think that moving functionality out of the standard library would damage Python, not improve it. Given that, I'd rather see what's in the stdlib be updated to best-of-breed, instead of the-first-thing-we-thought-of-in-1995, as all too much of it is. Bill From jim at zope.com Mon Feb 4 22:15:44 2008 From: jim at zope.com (Jim Fulton) Date: Mon, 4 Feb 2008 16:15:44 -0500 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <08Feb4.125024pst."58696"@synergy1.parc.xerox.com> References: <47A65121.1020703@colorstudy.com> <08Feb4.125024pst."58696"@synergy1.parc.xerox.com> Message-ID: On Feb 4, 2008, at 3:50 PM, Bill Janssen wrote: >> I think most web frameworks use setuptools at this point. I'd rather >> get this as a distribution, rather than from the standard library. >> In >> fact, I'd prefer to see all web-development libraries distributed >> separate from the language in Python 3. > > Jim, you want to have most things separate, if I've read your recent > posts to the dev and 3k lists correctly. Lean and mean Python > distribution. Yup. > I'd agree with you if we had the infrastructure for it, > something which would function at least as well as apt-get does, > pulling dependencies and doing platform and version checks > automatically. This is working now with setuptools. Overall, I think it is working pretty well. > But I don't think Python is anywhere near that level > of infrastructure, and it's a bit of a stretch just to maintain the > infrastructure that currently exists. The biggest problem I have with the current infrastructure is that it is unnecessarily dynamic and unreliable. Many of us are maintaining static mirrors that are working quite well. This is a pretty well understood problem at this point. > Given that, I think that moving > functionality out of the standard library would damage Python, not > improve it. OK, we disagree. I also, unfortunately, don't have a lot of time to contribute to Python 3, so I imagine that my opinion won't cary much weight, but I feel obliged, as a good citizen, to express it. > Given that, I'd rather see what's in the stdlib be > updated to best-of-breed, instead of > the-first-thing-we-thought-of-in-1995, as all too much of it is. Breeds are constantly evolving. I don't think it's realistic for the standard library to try to keep up. I also don't think it's a very good idea for language maintainers to make judgements about what's best in various application areas. I have the impression that there's this fairly large effort for people to redo lots of the standard library for Python 3, without necessarily knowing a lot about the libraries' histories, and motivation. I;m skeptical that this is going to lead to a high-quality product. I'd much rather see language developers put some focus on making a low- level feature like a packaging system work as well as possible. Jim -- Jim Fulton Zope Corporation From brett at python.org Mon Feb 4 22:21:39 2008 From: brett at python.org (Brett Cannon) Date: Mon, 4 Feb 2008 13:21:39 -0800 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <3824547301750077691@unknownmsgid> References: <47A65121.1020703@colorstudy.com> <3824547301750077691@unknownmsgid> Message-ID: On Feb 4, 2008 12:50 PM, Bill Janssen wrote: > > I think most web frameworks use setuptools at this point. I'd rather > > get this as a distribution, rather than from the standard library. In > > fact, I'd prefer to see all web-development libraries distributed > > separate from the language in Python 3. > > Jim, you want to have most things separate, if I've read your recent > posts to the dev and 3k lists correctly. Lean and mean Python > distribution. I'd agree with you if we had the infrastructure for it, > something which would function at least as well as apt-get does, > pulling dependencies and doing platform and version checks > automatically. But I don't think Python is anywhere near that level > of infrastructure, and it's a bit of a stretch just to maintain the > infrastructure that currently exists. Given that, I think that moving > functionality out of the standard library would damage Python, not > improve it. Given that, I'd rather see what's in the stdlib be > updated to best-of-breed, instead of > the-first-thing-we-thought-of-in-1995, as all too much of it is. So would I, but there is a deadline here. This needs to all be settled no later than this summer when 3.0 and 2.6 ship (whichever comes first). I just don't see how best-of-breed modules can get into the stdlib plus get deprecations going on the module all before that happens. Plus the stdlib reorg is about removing modules that need to go along with reorganizing what is there, not adding or replacing anything. Having said that, there is nothing saying the process can't start now to get rid of cruft that is still used and happen slowly over releases. So stuff that you guys think has been supplanted out in the world by other modules could be deprecated starting whenever. That makes me happy as it gives the chance for a better solution to come in. And it would make people like Jim happy as it gives the idea of shrinking the stdlib a chance to happen. -Brett From srichter at cosmos.phy.tufts.edu Tue Feb 5 02:07:41 2008 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Mon, 4 Feb 2008 20:07:41 -0500 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: References: <08Feb4.125024pst."58696"@synergy1.parc.xerox.com> Message-ID: <200802042007.41212.srichter@cosmos.phy.tufts.edu> On Monday 04 February 2008, Jim Fulton wrote: > Breeds are constantly evolving. ?I don't think it's realistic for the ? > standard library to try to keep up. ?I also don't think it's a very ? > good idea for language maintainers to make judgements about what's ? > best in various application areas. > > I have the impression that there's this fairly large effort for people ? > to redo lots of the standard library for Python 3, without necessarily ? > knowing a lot about the libraries' histories, and motivation. I;m ? > skeptical that this is going to lead to a high-quality product. > > I'd much rather see language developers put some focus on making a low- > level feature like a packaging system work as well as possible. Amen to that. :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" From guido at python.org Tue Feb 5 02:43:19 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 4 Feb 2008 17:43:19 -0800 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: <200802042007.41212.srichter@cosmos.phy.tufts.edu> References: <200802042007.41212.srichter@cosmos.phy.tufts.edu> Message-ID: On Feb 4, 2008 5:07 PM, Stephan Richter wrote: > On Monday 04 February 2008, Jim Fulton wrote: > > Breeds are constantly evolving. I don't think it's realistic for the > > standard library to try to keep up. I also don't think it's a very > > good idea for language maintainers to make judgements about what's > > best in various application areas. > > > > I have the impression that there's this fairly large effort for people > > to redo lots of the standard library for Python 3, without necessarily > > knowing a lot about the libraries' histories, and motivation. I;m > > skeptical that this is going to lead to a high-quality product. > > > > I'd much rather see language developers put some focus on making a low- > > level feature like a packaging system work as well as possible. > > Amen to that. :-) Sorry, but this is absurd. Packaging systems require a *very* different skill set and experience than language and library design. I think it's fair to give the language and library developers hints about which modules you want to keep, and why, and I believe all Brett did at the start of this thread was ask for feedback about a particular proposed module removal. He got it. AFAIK he hasn't pushed back. That should be the end of the story. But requesting that the *language* developers work on a packaging system is likely to give even worse results than expecting the language developers always to know how library modules are being used. And if you want to help, please join the stdlib-sig, rather than whining off-line! -- --Guido van Rossum (home page: http://www.python.org/~guido/) From mdipierro at cs.depaul.edu Tue Feb 5 03:26:52 2008 From: mdipierro at cs.depaul.edu (Massimo Di Pierro) Date: Mon, 4 Feb 2008 20:26:52 -0600 Subject: [Web-SIG] web2py 1.20 is out Message-ID: web2py 1.20 is out. www.web2py.com New features include the inclusion of a web based testing framework - a screenshot is here: http://web2py.googlegroups.com/web/test.tiff pyamf howto, rest support, handler for lighttpd/fcgi, WIKI helper, etc. AND it is always backward compatible. The source code is also on code.google.com/p/web2py Here are a dozen of ready made applications which you can install from the web interface. http://mdp.cti.depaul.edu/appliances Massimo From kevin at bud.ca Tue Feb 5 09:49:40 2008 From: kevin at bud.ca (Kevin Teague) Date: Tue, 5 Feb 2008 00:49:40 -0800 Subject: [Web-SIG] Removal of Cookie in Python 3.0 OK? In-Reply-To: References: <47A65121.1020703@colorstudy.com> Message-ID: <91BEED12-6609-49D1-B7B1-18A90C513A15@bud.ca> > I think most web frameworks use setuptools at this point. I'd rather > get this as a distribution, rather than from the standard library. In > fact, I'd prefer to see all web-development libraries distributed > separate from the language in Python 3. Keep in mind that there are two users of the web related standard python libraries. For web development I agree that using libraries distributed seperately from the python standard libraries is the way to go, but there are people who interact with the web that aren't doing web development per se. These libraries, especially the client- side ones, are used by people writing data processing tools, GUIs, one- off scripts, sys-admin tools, etc. For these people they may be perfectly happy doing all their Python needs with just the standard library - they don't want or need to learn about packaging and distributions when they just want to write a one-off script to pull some data off the web and output it into CSV. I've shown a hapless biology grad student who was going to manually copy thousands of records from a web app into Excel how this could be automated with a simple Python program. We ended up needing to use cookielib since the *$#&@*! web app we were scrapping data from was a bloated Java beast that required you to maintain session cookies (even though they served no purpose whatsoever ...). Trying to sort out why there was two cookie related libraries was an annoying stumbling block though, so +1 on removing Cookie and only keeping a re-named cookielib. From brett at python.org Wed Feb 6 00:21:17 2008 From: brett at python.org (Brett Cannon) Date: Tue, 5 Feb 2008 15:21:17 -0800 Subject: [Web-SIG] Merge Cookie and cookielib? Message-ID: Since Bill Janssen prodded me on to this list I might as well take advantage now and bug you all about how to deal with Cookie and cookielib in the stdlib reorg. My current idea is the new names cookie.client and cookie.server for Cookie and cookielib, respectively. While this goes against the goal of making the new names easier to work with, Cookie has to be renamed because of its PEP 8 violation. And having cookie and cookielib in the stdlib will not help with differentiating between the two. Merging them into a single cookie module blindly (as is happening with the various *HTTPServer modules) is not reasonable, though. Cookie has two classes names BaseCookie and SimpleCookie. cookielib has a class named Cookie. Cookie's classes have nothing to do with the classes exposed by cookielib. But obviously the names are similar enough to probably cause confusion for new users. Unfortunately 2to3 can't handle the renaming of a class from an imported module accurately like it can for imports since it works on a line-by-line basis. Fred Drake has suggested merging the two modules and renaming the stuff in the modules as needed. I'm fine with that, but that is beyond my role as the man with the big stick for the stdlib reorg. So my question is whether you all would be up for handling a merging of Cookie and cookielib for 2.6? I have no issue if you all want to take it as far as to deprecate both modules and come up with a new one that becomes http.cookie since that would probably be a PendingDeprecationWarning on the two modules and that won't impact Python 3.0 since all warnings must be dealt with to transition cleanly from 2.x to 3.0. Or if you just want to rename the classes that is fine by me as well. Either way this would be a 2.6 change that just happened to lead to 3.0 having only a single cookie-related module in the http package. -Brett From fumanchu at aminus.org Wed Feb 6 00:40:56 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Tue, 5 Feb 2008 15:40:56 -0800 Subject: [Web-SIG] Merge Cookie and cookielib? In-Reply-To: References: Message-ID: Brett Cannon wrote: > So my question is whether you all would be up for handling a merging > of Cookie and cookielib for 2.6? I appreciate the thought and effort for a smooth transition, but -1 on this idea if I understand it correctly. We have no plans to write a version of CherryPy which runs on both 2.x and 3.x, and even fewer plans to try autogenerating any part of CherryPy-for-Python-3 from the existing code, despite all the hard work on the 2to3 project. It's all going to be ported to Python 3 by hand to ensure our invariants are maintained. Therefore, rearranging any modules from 2.5 to 2.6 just makes more work for our team in the short term (lots of sys.version checking since we're still supporting Python 2.3) with zero gain in the long term. I'd rather just make one static name change (e.g. from "import Cookie" to "import cookie.server") in the new cp-python-3 branch and be done. Robert Brewer fumanchu at aminus.org From ianb at colorstudy.com Wed Feb 6 01:13:38 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 05 Feb 2008 18:13:38 -0600 Subject: [Web-SIG] Merge Cookie and cookielib? In-Reply-To: References: Message-ID: <47A8FBB2.3000000@colorstudy.com> Brett Cannon wrote: > Since Bill Janssen prodded me on to this list I might as well take > advantage now and bug you all about how to deal with Cookie and > cookielib in the stdlib reorg. > > My current idea is the new names cookie.client and cookie.server for > Cookie and cookielib, respectively. While this goes against the goal > of making the new names easier to work with, Cookie has to be renamed > because of its PEP 8 violation. And having cookie and cookielib in the > stdlib will not help with differentiating between the two. Somehow cookie.server doesn't seem right to me. cookie.client is reasonable -- cookielib is really intended to work with clients and implementing a browser-style persistent cookie database. The Cookie module, however, is more focused on just the parsing portions, which is largely symmetric between client and server. That there is a Cookie.Cookie class and a cookielib.Cookie class is somewhat unfortunate. cookielib.Cookie is actually a quite reasonable representation of cookies, more reasonable than Cookie.Cookie IMHO. Unfortunately the parsing routine in cookielib appears to be in CookieJar.make_cookies. If the parsing routines were separated from the jar stuff then cookielib (renamed or not) would probably be a usable replacement for Cookie, and instead of two stdlib modules those frameworks that didn't upgrade could ship their own Cookie module or depend on it. Using cookielib for a server-side framework would require more than a change in import statements. The Cookie module uses a weird dict-like pattern that is only really found in the Cookie module, like some historical artifact of lost Python patterns, so there's no real reason to keep that pattern except laziness. I however am probably too lazy with respect to this to depend on for more than this summary. Ian From brett at python.org Wed Feb 6 01:26:19 2008 From: brett at python.org (Brett Cannon) Date: Tue, 5 Feb 2008 16:26:19 -0800 Subject: [Web-SIG] Merge Cookie and cookielib? In-Reply-To: References: Message-ID: On Feb 5, 2008 3:40 PM, Robert Brewer wrote: > Brett Cannon wrote: > > So my question is whether you all would be up for handling a merging > > of Cookie and cookielib for 2.6? > > I appreciate the thought and effort for a smooth transition, but -1 on > this idea if I understand it correctly. > > We have no plans to write a version of CherryPy which runs on both 2.x > and 3.x, and even fewer plans to try autogenerating any part of > CherryPy-for-Python-3 from the existing code, despite all the hard work > on the 2to3 project. It's all going to be ported to Python 3 by hand to > ensure our invariants are maintained. Therefore, rearranging any modules > from 2.5 to 2.6 just makes more work for our team in the short term > (lots of sys.version checking since we're still supporting Python 2.3) > with zero gain in the long term. I'd rather just make one static name > change (e.g. from "import Cookie" to "import cookie.server") in the new > cp-python-3 branch and be done. Well, any rearrangement would still work in 2.6, just with a PendingDeprecationWarning. So no sys.version check would be needed to keep things running. -Brett From chris at simplistix.co.uk Thu Feb 7 17:48:04 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 07 Feb 2008 16:48:04 +0000 Subject: [Web-SIG] wsgiref for python 2.4? Message-ID: <47AB3644.4070404@simplistix.co.uk> Hi All, The subject line kindof says it all, but is there a wsgiref for python 2.4? Failing that, what's the lightest-weight wesgi server available for python 2.4? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From l.oluyede at gmail.com Thu Feb 7 17:51:32 2008 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Thu, 7 Feb 2008 17:51:32 +0100 Subject: [Web-SIG] wsgiref for python 2.4? In-Reply-To: <47AB3644.4070404@simplistix.co.uk> References: <47AB3644.4070404@simplistix.co.uk> Message-ID: <9eebf5740802070851kd927877t986204172a86cff3@mail.gmail.com> On Feb 7, 2008 5:48 PM, Chris Withers wrote: > Hi All, > > The subject line kindof says it all, but is there a wsgiref for python 2.4? Yes, it is. From adam at atlas.st Thu Feb 7 17:53:52 2008 From: adam at atlas.st (Adam Atlas) Date: Thu, 7 Feb 2008 11:53:52 -0500 Subject: [Web-SIG] wsgiref for python 2.4? In-Reply-To: <47AB3644.4070404@simplistix.co.uk> References: <47AB3644.4070404@simplistix.co.uk> Message-ID: <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> http://pypi.python.org/pypi/wsgiref It wouldn't hurt to look at CherryPy's WSGIServer anyway. I think it's generally a lot more efficient/scalable than the BaseHTTPServer-based implementation in wsgiref, and it's reasonably lightweight (one .py file, 1311 lines). http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py On 7 Feb 2008, at 11:48, Chris Withers wrote: > Hi All, > > The subject line kindof says it all, but is there a wsgiref for > python 2.4? > > Failing that, what's the lightest-weight wesgi server available for > python 2.4? > > cheers, > > Chris From chris at simplistix.co.uk Thu Feb 7 18:06:05 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu, 07 Feb 2008 17:06:05 +0000 Subject: [Web-SIG] wsgiref for python 2.4? In-Reply-To: <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> References: <47AB3644.4070404@simplistix.co.uk> <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> Message-ID: <47AB3A7D.600@simplistix.co.uk> Adam Atlas wrote: > http://pypi.python.org/pypi/wsgiref > > It wouldn't hurt to look at CherryPy's WSGIServer anyway. I think it's > generally a lot more efficient/scalable than the BaseHTTPServer-based > implementation in wsgiref, and it's reasonably lightweight (one .py > file, 1311 lines). > http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py What's the egg it's distributed in? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From mdipierro at cs.depaul.edu Thu Feb 7 18:44:33 2008 From: mdipierro at cs.depaul.edu (Massimo Di Pierro) Date: Thu, 7 Feb 2008 11:44:33 -0600 Subject: [Web-SIG] wsgiref for python 2.4? In-Reply-To: <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> References: <47AB3644.4070404@simplistix.co.uk> <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> Message-ID: <57606583-FBC3-4329-A97F-27248934C27A@cs.depaul.edu> Could somebody discuss pros and cons of cherrypy wsgiserver vs paste httserver? Massimo On Feb 7, 2008, at 10:53 AM, Adam Atlas wrote: > http://pypi.python.org/pypi/wsgiref > > It wouldn't hurt to look at CherryPy's WSGIServer anyway. I think it's > generally a lot more efficient/scalable than the BaseHTTPServer-based > implementation in wsgiref, and it's reasonably lightweight (one .py > file, 1311 lines). > http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py > > > On 7 Feb 2008, at 11:48, Chris Withers wrote: >> Hi All, >> >> The subject line kindof says it all, but is there a wsgiref for >> python 2.4? >> >> Failing that, what's the lightest-weight wesgi server available for >> python 2.4? >> >> cheers, >> >> Chris > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/ > mdipierro%40cti.depaul.edu From chris at simplistix.co.uk Fri Feb 8 12:42:41 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 08 Feb 2008 11:42:41 +0000 Subject: [Web-SIG] wsgiref for python 2.4? In-Reply-To: <47AB3FAD.5080603@100blossoms.com> References: <47AB3644.4070404@simplistix.co.uk> <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> <47AB3A7D.600@simplistix.co.uk> <47AB3FAD.5080603@100blossoms.com> Message-ID: <47AC4031.8060107@simplistix.co.uk> Luis Bruno wrote: > Chris Withers escreveu: >> Adam Atlas wrote: >> >>> http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py >>> >> >> What's the egg it's distributed in? >> > > I normally use egg:PasteScript#cherrypy I'm afraid I have no idea what this means... can you explain? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From lbruno at 100blossoms.com Fri Feb 8 15:54:53 2008 From: lbruno at 100blossoms.com (Luis Bruno) Date: Fri, 08 Feb 2008 14:54:53 +0000 Subject: [Web-SIG] wsgiref for python 2.4? In-Reply-To: <47AC4031.8060107@simplistix.co.uk> References: <47AB3644.4070404@simplistix.co.uk> <2E1D823D-47DB-4DA5-8C14-3B6DE2B5387B@atlas.st> <47AB3A7D.600@simplistix.co.uk> <47AB3FAD.5080603@100blossoms.com> <47AC4031.8060107@simplistix.co.uk> Message-ID: <47AC6D3D.2020908@100blossoms.com> Chris Withers wrote: > Luis Bruno wrote: >> I normally use egg:PasteScript#cherrypy > I'm afraid I have no idea what this means... can you explain? I "easy_install -Z CherryPy"; I found no .egg, just a source tarball; does it make a difference? I answered the "where is the Paste server_factory entry point?" question; after a careful re-read of your post, I see that was not the question you wanted answered; sorry! From guido at python.org Sat Feb 9 05:18:56 2008 From: guido at python.org (Guido van Rossum) Date: Fri, 8 Feb 2008 20:18:56 -0800 Subject: [Web-SIG] Fwd: [Baypiggies] News flash: Python possibly guilty in excessive DTD traffic In-Reply-To: <20080209040312.725218a2@dartworks.biz> References: <20080209040312.725218a2@dartworks.biz> Message-ID: ---------- Forwarded message ---------- From: Keith Dart ♂ Date: Feb 8, 2008 8:03 PM Subject: [Baypiggies] News flash: Python possibly guilty in excessive DTD traffic To: baypiggies at python.org http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic This is interesting. I've noticed that when you use Python's XML package in validating mode it does try to fetch the DTD. Be careful when you use that. -- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Keith Dart public key: ID: 19017044 ===================================================================== _______________________________________________ Baypiggies mailing list Baypiggies at python.org To change your subscription options or unsubscribe: http://mail.python.org/mailman/listinfo/baypiggies -- --Guido van Rossum (home page: http://www.python.org/~guido/) From jeffpeery at yahoo.com Sun Feb 10 08:56:00 2008 From: jeffpeery at yahoo.com (Jeff Peery) Date: Sat, 9 Feb 2008 23:56:00 -0800 (PST) Subject: [Web-SIG] newbie help with httpsconnection Message-ID: <669727.87345.qm@web43141.mail.sp1.yahoo.com> Hello, I'm stumped. I'm trying to run the following bit of code in a cgi script. httpServ = httplib.HTTPSConnection('https://secure.authorize.net') # connect to gateway httpServ.connect() # serve request params = urllib.urlencode(fm, '|') httpServ.request('POST', '/gateway/transact.dll', params) # close connection httpServ.close() I get this error when httpSerc.connect() is called: gaierror: (-2, 'Name or service not known') args = (-2, 'Name or service not known') what am I doing wrong? Thanks! Jeff --------------------------------- Never miss a thing. Make Yahoo your homepage. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20080209/00d20532/attachment.htm From mdipierro at cs.depaul.edu Sun Feb 10 09:03:20 2008 From: mdipierro at cs.depaul.edu (Massimo Di Pierro) Date: Sun, 10 Feb 2008 02:03:20 -0600 Subject: [Web-SIG] new in trunk. please read Message-ID: <63D5955C-229D-4999-AC69-275CC44C6138@cs.depaul.edu> There is a new version in code.google.com/p/web2py trunk. For Niccolo: I think I fixed the problem with uploading large files. Could you please run some tests to confirm memory usage. For voltron: The pidfile is now deleted on exit. Mind that in your pyamf hander you have to replace request.body with request.body.read() Now request.body is a temporary file to deal with large inputs. For anybody using XMLRPC: Do not use the example appliance. Use def handler(): response.xmlrpc(request,methods) where methods is the list of exposed methods. If not clear, ASK ME. For my students: you get points if you test this and report bugs/typos/correction/etc (or just confirm that nothing breaks) by Monday. The GUI now shows a graph of incoming requests. Use web2py.py -h for help on how to use SSL/HTTPS. Massimo From exarkun at divmod.com Sun Feb 10 18:11:07 2008 From: exarkun at divmod.com (Jean-Paul Calderone) Date: Sun, 10 Feb 2008 12:11:07 -0500 Subject: [Web-SIG] newbie help with httpsconnection In-Reply-To: <669727.87345.qm@web43141.mail.sp1.yahoo.com> Message-ID: <20080210171107.6859.1598674400.divmod.quotient.7759@ohm> On Sat, 9 Feb 2008 23:56:00 -0800 (PST), Jeff Peery wrote: >Hello, > I'm stumped. I'm trying to run the following bit of code in a cgi script. > > httpServ = httplib.HTTPSConnection('https://secure.authorize.net') The first parameter to HTTPSConnection is supposed to be a hostname. Jean-Paul From petite.abeille at gmail.com Mon Feb 18 00:20:54 2008 From: petite.abeille at gmail.com (Petite Abeille) Date: Mon, 18 Feb 2008 00:20:54 +0100 Subject: [Web-SIG] [OT][ANN] Nanoki Message-ID: [Not even remotely related to Python, WSGI, Guido van Rossum or anything] Nanoki, a sweet little wiki engine implemented in Lua [1]. http://alt.textdrive.com/nanoki/ Online demo: http://svr225.stepx.com:3388/nanoki Kind regards, PA. [1] http://www.lua.org/about.html From brett at python.org Wed Feb 20 11:21:00 2008 From: brett at python.org (Brett Cannon) Date: Wed, 20 Feb 2008 02:21:00 -0800 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? Message-ID: I started a discussion about creating an html package over on the stdlib-sig when I realized that htmllib and HTMLParser seem really similar. Are both modules needed at this point? Otherwise something like html.parser and html.xparser will be needed to tell them apart in the package since they both use the same name for the classes they contain. -Brett From guido at python.org Wed Feb 20 15:35:18 2008 From: guido at python.org (Guido van Rossum) Date: Wed, 20 Feb 2008 06:35:18 -0800 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? In-Reply-To: References: Message-ID: ISTR that HTMLParser was the preferred one. It is certainly newer, and doesn't carry the baggage of sgmllib which I would discard together with htmllib). Maybe Fred Drake remembers (he's listed as the co-author on the initial checkin message). On Feb 20, 2008 2:21 AM, Brett Cannon wrote: > I started a discussion about creating an html package over on the > stdlib-sig when I realized that htmllib and HTMLParser seem really > similar. Are both modules needed at this point? Otherwise something > like html.parser and html.xparser will be needed to tell them apart in > the package since they both use the same name for the classes they > contain. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at gmail.com Wed Feb 20 16:43:26 2008 From: fdrake at gmail.com (Fred Drake) Date: Wed, 20 Feb 2008 10:43:26 -0500 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? In-Reply-To: References: Message-ID: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> On Feb 20, 2008 9:35 AM, Guido van Rossum wrote: > ISTR that HTMLParser was the preferred one. It is certainly newer, and > doesn't carry the baggage of sgmllib which I would discard together > with htmllib). Maybe Fred Drake remembers (he's listed as the > co-author on the initial checkin message). I was thinking I'd said something on the stdlib-sig list, but I can't find it in the archive, so I must be having a senior moment (brought on early by kids). I'd be in favor of keeping only HTMLParser, with a compliant module name ("htmlparser" doesn't seem unreasonable). The code was originally derived from htmllib for the Grail webbrowser, mostly to make things like attribute handling less painful. Merging _markupbase into HTMLParser to create htmlparser would be pretty mechanical. Removing sgmllib and htmllib does not depend on that, and can be done at any time if there's agreement. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From chris at simplistix.co.uk Wed Feb 20 19:43:18 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 20 Feb 2008 18:43:18 +0000 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? In-Reply-To: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> References: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> Message-ID: <47BC74C6.2030107@simplistix.co.uk> Fred Drake wrote: > I'd be in favor of keeping only HTMLParser, with a compliant module > name ("htmlparser" doesn't seem unreasonable). The code was > originally derived from htmllib for the Grail webbrowser, mostly to > make things like attribute handling less painful. Really? Cool. My first encounter with HTMLParser was when it was used for Zope's ZPT engine. I have memories of petitioning Guido to get it into the standard library at the time, although I guess my petitioning and its real reason for inclusion may have been coincidental. It's been a while since I had to use an html parser directly, but from what I remember, HTMLParser is much less of a PITA than the available standard library alternatives... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From fdrake at gmail.com Wed Feb 20 20:31:24 2008 From: fdrake at gmail.com (Fred Drake) Date: Wed, 20 Feb 2008 14:31:24 -0500 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? In-Reply-To: <47BC74C6.2030107@simplistix.co.uk> References: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> <47BC74C6.2030107@simplistix.co.uk> Message-ID: <9cee7ab80802201131w49ceb401med72f8f797208e85@mail.gmail.com> On Feb 20, 2008 1:43 PM, Chris Withers wrote: > Really? Cool. My first encounter with HTMLParser was when it was used > for Zope's ZPT engine. Oh, maybe that was it. Something from the distant past at any rate. :-) If I had a hand in it, it was certainly colored by using htmllib for more than it was intended in Grail; we did end up with our own HTML parser in that project at one point. At least I worked on one for it. (Memory's failing...) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From brett at python.org Wed Feb 20 21:27:34 2008 From: brett at python.org (Brett Cannon) Date: Wed, 20 Feb 2008 12:27:34 -0800 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? In-Reply-To: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> References: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> Message-ID: On Feb 20, 2008 7:43 AM, Fred Drake wrote: > On Feb 20, 2008 9:35 AM, Guido van Rossum wrote: > > ISTR that HTMLParser was the preferred one. It is certainly newer, and > > doesn't carry the baggage of sgmllib which I would discard together > > with htmllib). Maybe Fred Drake remembers (he's listed as the > > co-author on the initial checkin message). > > I was thinking I'd said something on the stdlib-sig list, but I can't > find it in the archive, so I must be having a senior moment (brought > on early by kids). > > I'd be in favor of keeping only HTMLParser, with a compliant module > name ("htmlparser" doesn't seem unreasonable). The code was > originally derived from htmllib for the Grail webbrowser, mostly to > make things like attribute handling less painful. > > Merging _markupbase into HTMLParser to create htmlparser would be > pretty mechanical. Removing sgmllib and htmllib does not depend on > that, and can be done at any time if there's agreement. > Works for me. Then the current plan is: HTMLParser -> html.parser htmlentitydefs -> html.entities And remove both htmllib and sgmllib. I will run this by the stdlib-sig as well. -Brett From fdrake at gmail.com Wed Feb 20 22:01:09 2008 From: fdrake at gmail.com (Fred Drake) Date: Wed, 20 Feb 2008 16:01:09 -0500 Subject: [Web-SIG] Are both htmllib and HTMLParser needed? In-Reply-To: References: <9cee7ab80802200743l2edacf81u3c940f4e27593ee6@mail.gmail.com> Message-ID: <9cee7ab80802201301l744a3a59xcfd6946161ddba60@mail.gmail.com> On Feb 20, 2008 3:27 PM, Brett Cannon wrote: > HTMLParser -> html.parser > htmlentitydefs -> html.entities > > And remove both htmllib and sgmllib. Something I mentioned on stdlib-sig was that "formatter" might be worth thinking about in this. Is anyone using that module for anything other than formatting HTML? -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From brett at python.org Wed Feb 20 22:52:32 2008 From: brett at python.org (Brett Cannon) Date: Wed, 20 Feb 2008 13:52:32 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse Message-ID: So the conundrum here is that urllib and urllib2 are both used extensively and both have their key function named urlopen(). MAL has suggested: urllib -> url.fetch urllib2 -> url.request urlparser -> url.parse which I am liking. But I figured I would ask if there is any remote chance the this SIG has plans to either merge urllib and urllib2 or come up with a new module, or something before 3.0 comes out. Otherwise MAL's names will probably be the suggested new names and one can hope at some point one of the urllib* modules can go away. -Brett From fumanchu at aminus.org Wed Feb 20 23:02:53 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Wed, 20 Feb 2008 14:02:53 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: Message-ID: Brett Cannon wrote: > So the conundrum here is that urllib and urllib2 are both used > extensively and both have their key function named urlopen(). MAL has > suggested: > > urllib -> url.fetch > urllib2 -> url.request > urlparser -> url.parse > > which I am liking. But I figured I would ask if there is any remote > chance the this SIG has plans to either merge urllib and urllib2 or > come up with a new module, or something before 3.0 comes out. > Otherwise MAL's names will probably be the suggested new names and one > can hope at some point one of the urllib* modules can go away. I like the above too, and I can't recall anyone talking about merging or replacing urllib(2) in the multiple years I've been on this list. :) So +1. Robert Brewer fumanchu at aminus.org From ianb at colorstudy.com Wed Feb 20 23:48:19 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 20 Feb 2008 16:48:19 -0600 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: Message-ID: <47BCAE33.3060606@colorstudy.com> Brett Cannon wrote: > which I am liking. But I figured I would ask if there is any remote > chance the this SIG has plans to either merge urllib and urllib2 or > come up with a new module, or something before 3.0 comes out. httplib2 is basically a replacement for urllib. I personally prefer it to urllib. I don't know how other people feel, or Joe's thoughts (the author). Somewhat ironically httplib2 has a scope that is closer to urllib than httplib. It would be nice if this naming style (x and x2) didn't persist. Ian From guido at python.org Wed Feb 20 23:52:32 2008 From: guido at python.org (Guido van Rossum) Date: Wed, 20 Feb 2008 14:52:32 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <47BCAE33.3060606@colorstudy.com> References: <47BCAE33.3060606@colorstudy.com> Message-ID: Are you sure you don't mean urllib2? I *know* that urllib2 is a replacement for urllib. AFAIK there is no httplib2... On Wed, Feb 20, 2008 at 2:48 PM, Ian Bicking wrote: > Brett Cannon wrote: > > which I am liking. But I figured I would ask if there is any remote > > chance the this SIG has plans to either merge urllib and urllib2 or > > come up with a new module, or something before 3.0 comes out. > > httplib2 is basically a replacement for urllib. I personally prefer it > to urllib. I don't know how other people feel, or Joe's thoughts (the > author). > > Somewhat ironically httplib2 has a scope that is closer to urllib than > httplib. It would be nice if this naming style (x and x2) didn't persist. > > Ian > > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) From ianb at colorstudy.com Wed Feb 20 23:53:48 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 20 Feb 2008 16:53:48 -0600 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: <47BCAE33.3060606@colorstudy.com> Message-ID: <47BCAF7C.2090506@colorstudy.com> Guido van Rossum wrote: > Are you sure you don't mean urllib2? I *know* that urllib2 is a > replacement for urllib. AFAIK there is no httplib2... Sorry, should have linked: http://code.google.com/p/httplib2/ Ian From brett at python.org Thu Feb 21 02:16:39 2008 From: brett at python.org (Brett Cannon) Date: Wed, 20 Feb 2008 17:16:39 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <47BCAE33.3060606@colorstudy.com> References: <47BCAE33.3060606@colorstudy.com> Message-ID: On Wed, Feb 20, 2008 at 2:48 PM, Ian Bicking wrote: > Brett Cannon wrote: > > which I am liking. But I figured I would ask if there is any remote > > chance the this SIG has plans to either merge urllib and urllib2 or > > come up with a new module, or something before 3.0 comes out. > > httplib2 is basically a replacement for urllib. I personally prefer it > to urllib. I don't know how other people feel, or Joe's thoughts (the > author). > Since no one has stepped forward to go through the hoops necessary to get it into the stdlib I am not going to worry about it for this issue. > Somewhat ironically httplib2 has a scope that is closer to urllib than > httplib. It would be nice if this naming style (x and x2) didn't persist. > That's the point of this endeavor. It has been suggested by Fred on the stdlib-sig that urllib should just be tossed in favor of urllib2 since most people probably just use urlopen() and that is mostly compatible between the two. What do people think of that idea? -Brett From janssen at parc.com Thu Feb 21 02:57:19 2008 From: janssen at parc.com (Bill Janssen) Date: Wed, 20 Feb 2008 17:57:19 PST Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: <47BCAE33.3060606@colorstudy.com> Message-ID: <08Feb20.175720pst."58696"@synergy1.parc.xerox.com> > It has been suggested by Fred on the stdlib-sig that urllib should > just be tossed in favor of urllib2 since most people probably just use > urlopen() and that is mostly compatible between the two. What do > people think of that idea? A quick grep shows that I use "quote", "quote_plus", "unquote", and "unquote_plus" from urllib. Not sure how representative that is, but they should at least be preserved in urllib2. By the way, shouldn't the name "urllib" be used for "urllib2", if "urllib" is tossed? Bill From fdrake at gmail.com Thu Feb 21 03:38:16 2008 From: fdrake at gmail.com (Fred Drake) Date: Wed, 20 Feb 2008 21:38:16 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <1730576685614834017@unknownmsgid> References: <47BCAE33.3060606@colorstudy.com> <1730576685614834017@unknownmsgid> Message-ID: <9cee7ab80802201838n5c44b287ld6f41a749da61c06@mail.gmail.com> On Wed, Feb 20, 2008 at 8:57 PM, Bill Janssen wrote: > A quick grep shows that I use "quote", "quote_plus", "unquote", and > "unquote_plus" from urllib. Not sure how representative that is, but Those are probably pretty commonly in use, I suppose. They should definitely be preserved somewhere. > they should at least be preserved in urllib2. By the way, shouldn't > the name "urllib" be used for "urllib2", if "urllib" is tossed? No. The names urllib and urllib2 should both be tossed. The *lib naming convention is horrible and should die a painful death. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From titus at caltech.edu Thu Feb 21 03:40:22 2008 From: titus at caltech.edu (Titus Brown) Date: Wed, 20 Feb 2008 18:40:22 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <9cee7ab80802201838n5c44b287ld6f41a749da61c06@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <1730576685614834017@unknownmsgid> <9cee7ab80802201838n5c44b287ld6f41a749da61c06@mail.gmail.com> Message-ID: <20080221024021.GA32134@caltech.edu> On Wed, Feb 20, 2008 at 09:38:16PM -0500, Fred Drake wrote: -> On Wed, Feb 20, 2008 at 8:57 PM, Bill Janssen wrote: -> > A quick grep shows that I use "quote", "quote_plus", "unquote", and -> > "unquote_plus" from urllib. Not sure how representative that is, but -> -> Those are probably pretty commonly in use, I suppose. They should -> definitely be preserved somewhere. yes -> > they should at least be preserved in urllib2. By the way, shouldn't -> > the name "urllib" be used for "urllib2", if "urllib" is tossed? -> -> No. The names urllib and urllib2 should both be tossed. The *lib -> naming convention is horrible and should die a painful death. +inf --titus From brett at python.org Thu Feb 21 05:35:19 2008 From: brett at python.org (Brett Cannon) Date: Wed, 20 Feb 2008 20:35:19 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <9cee7ab80802201838n5c44b287ld6f41a749da61c06@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <1730576685614834017@unknownmsgid> <9cee7ab80802201838n5c44b287ld6f41a749da61c06@mail.gmail.com> Message-ID: On Wed, Feb 20, 2008 at 6:38 PM, Fred Drake wrote: > On Wed, Feb 20, 2008 at 8:57 PM, Bill Janssen wrote: > > A quick grep shows that I use "quote", "quote_plus", "unquote", and > > "unquote_plus" from urllib. Not sure how representative that is, but > > Those are probably pretty commonly in use, I suppose. They should > definitely be preserved somewhere. > Right. I would never toss that part of the module. > > > they should at least be preserved in urllib2. By the way, shouldn't > > the name "urllib" be used for "urllib2", if "urllib" is tossed? > > No. The names urllib and urllib2 should both be tossed. The *lib > naming convention is horrible and should die a painful death. Trying my best. =) -Brett From joe at bitworking.org Fri Feb 22 04:34:22 2008 From: joe at bitworking.org (Joe Gregorio) Date: Thu, 21 Feb 2008 22:34:22 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: <47BCAE33.3060606@colorstudy.com> Message-ID: <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> On Wed, Feb 20, 2008 at 8:16 PM, Brett Cannon wrote: > On Wed, Feb 20, 2008 at 2:48 PM, Ian Bicking wrote: > > > Brett Cannon wrote: > > > which I am liking. But I figured I would ask if there is any remote > > > chance the this SIG has plans to either merge urllib and urllib2 or > > > come up with a new module, or something before 3.0 comes out. > > > > httplib2 is basically a replacement for urllib. I personally prefer it > > to urllib. I don't know how other people feel, or Joe's thoughts (the > > author). > > > > Since no one has stepped forward to go through the hoops necessary to > get it into the stdlib I am not going to worry about it for this > issue. I submitted my contributor agreement a while ago, so it should be on file. My goal has always been to bring forward httplib2 for inclusion in the std lib, but I didn't want to do that until I got support for proxies, which just recently went in, and then there's starting to work at Google which has soaked up all my time as I got up to speed. Anyway, enough excuses. I am willing to go through the hoops necessary to get into the std lib if someone wants to guide me in that process. Thanks, -joe > > Somewhat ironically httplib2 has a scope that is closer to urllib than > > httplib. It would be nice if this naming style (x and x2) didn't persist. > > > > That's the point of this endeavor. > > It has been suggested by Fred on the stdlib-sig that urllib should > just be tossed in favor of urllib2 since most people probably just use > urlopen() and that is mostly compatible between the two. What do > people think of that idea? > > -Brett > -- Joe Gregorio http://bitworking.org From l.oluyede at gmail.com Fri Feb 22 09:20:13 2008 From: l.oluyede at gmail.com (Lawrence Oluyede) Date: Fri, 22 Feb 2008 09:20:13 +0100 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> Message-ID: <9eebf5740802220020x4c25524l581bc901d46cdf88@mail.gmail.com> > I submitted my contributor agreement a while ago, so it should be on file. > My goal has always been to bring forward httplib2 for inclusion in the > std lib, but I didn't want to do that until I got support for proxies, which > just recently went in, and then there's starting to work at Google > which has soaked up all my time as I got up to speed. Anyway, enough > excuses. Don't know if my opinion is valuable since I'm only a user of httplib2, but I'd love to see that library in the stdlib :-) Even with some little API changes if you have to! -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair From brett at python.org Fri Feb 22 10:16:53 2008 From: brett at python.org (Brett Cannon) Date: Fri, 22 Feb 2008 01:16:53 -0800 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> Message-ID: On Thu, Feb 21, 2008 at 7:34 PM, Joe Gregorio wrote: > On Wed, Feb 20, 2008 at 8:16 PM, Brett Cannon wrote: > > On Wed, Feb 20, 2008 at 2:48 PM, Ian Bicking wrote: > > > > > Brett Cannon wrote: > > > > which I am liking. But I figured I would ask if there is any remote > > > > chance the this SIG has plans to either merge urllib and urllib2 or > > > > come up with a new module, or something before 3.0 comes out. > > > > > > httplib2 is basically a replacement for urllib. I personally prefer it > > > to urllib. I don't know how other people feel, or Joe's thoughts (the > > > author). > > > > > > > Since no one has stepped forward to go through the hoops necessary to > > get it into the stdlib I am not going to worry about it for this > > issue. > > I submitted my contributor agreement a while ago, so it should be on file. > My goal has always been to bring forward httplib2 for inclusion in the > std lib, but I didn't want to do that until I got support for proxies, which > just recently went in, and then there's starting to work at Google > which has soaked up all my time as I got up to speed. New jobs tend to do that, especially Google. > Anyway, enough > excuses. > > I am willing to go through the hoops necessary to get into the std lib > if someone wants to guide me in that process. The general steps are (in no particular order): * Have the code written and meeting PEP 7/8 standards. * Thorough unit tests using unittest or doctest. * Full documentation ready to go in the proper format. * Promise to maintain the code for at least a couple of years and have your contrib agreement in. * Use Python's issue tracker and svn repository as the main point of development. * Have the community consider it best-of-breed. * Convince the stdlib-sig that it is a good addition and then python-dev. I think that's everything. =) If you have more questions you can email the stdlib-sig and/or me. -Brett From joe at bitworking.org Fri Feb 22 17:00:00 2008 From: joe at bitworking.org (Joe Gregorio) Date: Fri, 22 Feb 2008 11:00:00 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> Message-ID: <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> On Fri, Feb 22, 2008 at 4:16 AM, Brett Cannon wrote: > * Have the code written and meeting PEP 7/8 standards. Done. Well, as far as I can tell, though the distribution of the code might not conform as there it a lot of code in __init_.py. > * Thorough unit tests using unittest or doctest. Done. http://httplib2.googlecode.com/svn/trunk/httplib2test.py Many unit tests done in unittest. They fall into two categories, those that run locally and those that run against a set of URIs on the web. Is there a stdlib way of segregating those tests? All the code for the resources is also checked into subversion: http://httplib2.googlecode.com/svn/trunk/test/ > * Full documentation ready to go in the proper format. Done. http://bitworking.org/projects/httplib2/ref/ > * Promise to maintain the code for at least a couple of years and have > your contrib agreement in. Agreed. And done. > * Use Python's issue tracker and svn repository as the main point of > development. Agreed. > * Have the community consider it best-of-breed. Generally out of my hands, but I can point out that Ubuntu, Debian, Gentoo and FreeBSD all currently include httplib2. > * Convince the stdlib-sig that it is a good addition and then python-dev. Subscribed. > > I think that's everything. =) If you have more questions you can email > the stdlib-sig and/or me. Thanks! -joe -- Joe Gregorio http://bitworking.org From fdrake at gmail.com Fri Feb 22 19:45:51 2008 From: fdrake at gmail.com (Fred Drake) Date: Fri, 22 Feb 2008 13:45:51 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> Message-ID: <9cee7ab80802221045r55428c25x9becafc3dc123a06@mail.gmail.com> On Fri, Feb 22, 2008 at 11:00 AM, Joe Gregorio wrote: > Many unit tests done in unittest. They fall into > two categories, those that run locally and those > that run against a set of URIs on the web. Is there > a stdlib way of segregating those tests? All the > code for the resources is also checked into > subversion: > > http://httplib2.googlecode.com/svn/trunk/test/ See test.test_support.is_resource_enabled(). You probably care about the 'network' resource. > > * Full documentation ready to go in the proper format. > > Done. > > http://bitworking.org/projects/httplib2/ref/ This looks like you used the old LaTeX format; there's a new format starting with Python 2.6: http://docs.python.org/dev/documenting/index.html -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From ianb at colorstudy.com Fri Feb 22 20:09:41 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 22 Feb 2008 13:09:41 -0600 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> Message-ID: <47BF1DF5.4050403@colorstudy.com> Joe Gregorio wrote: >> * Thorough unit tests using unittest or doctest. > > Done. > > http://httplib2.googlecode.com/svn/trunk/httplib2test.py > > Many unit tests done in unittest. They fall into > two categories, those that run locally and those > that run against a set of URIs on the web. Is there > a stdlib way of segregating those tests? All the > code for the resources is also checked into > subversion: > > http://httplib2.googlecode.com/svn/trunk/test/ I guess this is a test-related feature request: something that would be nice, and that I don't believe httplib2 specifically allows (though maybe I am unaware of it) is a clear/documented way to mock http calls. wsgi_intercept provides this in a kind of general way, and includes some httplib2 support, but direct support in httplib2 (and the stdlib) would be very nice, and I think encourage people to do better testing. Ian From joe at bitworking.org Fri Feb 22 20:08:41 2008 From: joe at bitworking.org (Joe Gregorio) Date: Fri, 22 Feb 2008 14:08:41 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <9cee7ab80802221045r55428c25x9becafc3dc123a06@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> <9cee7ab80802221045r55428c25x9becafc3dc123a06@mail.gmail.com> Message-ID: <3f1451f50802221108l75cce390s70702e9829a98029@mail.gmail.com> On Fri, Feb 22, 2008 at 1:45 PM, Fred Drake wrote: > This looks like you used the old LaTeX format; there's a new format > starting with Python 2.6: > > http://docs.python.org/dev/documenting/index.html Oh, reST, cool. Is there a tool for doing the majority of the work of converting the old LaTeX into reST? Thanks, -joe -- Joe Gregorio http://bitworking.org From fdrake at gmail.com Fri Feb 22 20:40:22 2008 From: fdrake at gmail.com (Fred Drake) Date: Fri, 22 Feb 2008 14:40:22 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <3f1451f50802221108l75cce390s70702e9829a98029@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> <9cee7ab80802221045r55428c25x9becafc3dc123a06@mail.gmail.com> <3f1451f50802221108l75cce390s70702e9829a98029@mail.gmail.com> Message-ID: <9cee7ab80802221140p25ec59f6h63ea5505877e032b@mail.gmail.com> On Fri, Feb 22, 2008 at 2:08 PM, Joe Gregorio wrote: > Is there a tool for doing the majority of the work of converting the > old LaTeX into reST? I think there is; if you ask python-docs python.org, you'll be asking the people who know. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From joe at bitworking.org Fri Feb 22 20:51:16 2008 From: joe at bitworking.org (Joe Gregorio) Date: Fri, 22 Feb 2008 14:51:16 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <47BF1DF5.4050403@colorstudy.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> <47BF1DF5.4050403@colorstudy.com> Message-ID: <3f1451f50802221151v63de086mc887699d69f577aa@mail.gmail.com> On Fri, Feb 22, 2008 at 2:09 PM, Ian Bicking wrote: > I guess this is a test-related feature request: something that would be > nice, and that I don't believe httplib2 specifically allows (though > maybe I am unaware of it) is a clear/documented way to mock http calls. > wsgi_intercept provides this in a kind of general way, and includes > some httplib2 support, but direct support in httplib2 (and the stdlib) > would be very nice, and I think encourage people to do better testing. I have a MockHttp in another project that I use for testing code that uses httplib2, is this what you'd like to see included in httplib2 itself? http://code.google.com/p/feedvalidator/source/browse/trunk/apptestsuite/client/atompubbase/tests/mockhttp.py Thanks, -joe -- Joe Gregorio http://bitworking.org From ianb at colorstudy.com Fri Feb 22 23:21:39 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 22 Feb 2008 16:21:39 -0600 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: <3f1451f50802221151v63de086mc887699d69f577aa@mail.gmail.com> References: <47BCAE33.3060606@colorstudy.com> <3f1451f50802211934o2156d8c4s16dbb3fe8043dc55@mail.gmail.com> <3f1451f50802220800s3753b548j58daf4d9f27dab18@mail.gmail.com> <47BF1DF5.4050403@colorstudy.com> <3f1451f50802221151v63de086mc887699d69f577aa@mail.gmail.com> Message-ID: <47BF4AF3.9000806@colorstudy.com> Joe Gregorio wrote: > On Fri, Feb 22, 2008 at 2:09 PM, Ian Bicking wrote: >> I guess this is a test-related feature request: something that would be >> nice, and that I don't believe httplib2 specifically allows (though >> maybe I am unaware of it) is a clear/documented way to mock http calls. >> wsgi_intercept provides this in a kind of general way, and includes >> some httplib2 support, but direct support in httplib2 (and the stdlib) >> would be very nice, and I think encourage people to do better testing. > > I have a MockHttp in another project that I use for testing code > that uses httplib2, is this what you'd like to see included in > httplib2 itself? > > http://code.google.com/p/feedvalidator/source/browse/trunk/apptestsuite/client/atompubbase/tests/mockhttp.py Yes, more or less. Only taking from files on disk is less flexible than a WSGI application, so that more general interface would also be nice (though having both would be good too). Ian From orsenthil at gmail.com Sat Feb 23 00:08:05 2008 From: orsenthil at gmail.com (Senthil Kumaran) Date: Fri, 22 Feb 2008 18:08:05 -0500 Subject: [Web-SIG] Dealing with urllib, urllib2, and urlparse In-Reply-To: References: Message-ID: <7c42eba10802221508h2b459ee2sb1d620b9f3b1f209@mail.gmail.com> On Wed, Feb 20, 2008 at 4:52 PM, Brett Cannon wrote: > which I am liking. But I figured I would ask if there is any remote > chance the this SIG has plans to either merge urllib and urllib2 or > come up with a new module, or something before 3.0 comes out. > Otherwise MAL's names will probably be the suggested new names and one > can hope at some point one of the urllib* modules can go away. > > -Brett Sorry for pitching in late. It is good that this topic got started well. I had submitted this task as G-SoC and went ahead with fixing bugs with urllib2 and merging the overlapping methods. http://svn.python.org/view/sandbox/trunk/urilib/ As you can see, I have not worked it quite a while and I have always been "thinking" of emailing WSIG to go ahead with the project. I would like to continue working on the same and would like to invite other interested parties as well. Yes, with some guidance, I hope that we can bring up the urilib (urlllib2,urllib,urlparse combined and according latest URI Spec) before Python 3.0. I shall have a look into httplib2 which is referenced in this thread as well. Please let me know your comments. Thanks, Senthil -- O.R.Senthil Kumaran http://phoe6.livejournal.com From brett at python.org Fri Feb 29 01:47:22 2008 From: brett at python.org (Brett Cannon) Date: Thu, 28 Feb 2008 16:47:22 -0800 Subject: [Web-SIG] Choosing one of two options for url* in the stdlib reorg Message-ID: [BCC'ing stdlib-sig and web-sig so that both vote but that I don't have to clear a bunch of replies in the stdlib-sig mailing list from people not on both lists =) ] With PyCon approaching and having other stuff on my plate to deal with I want to try to reach a consensus on the whole urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0 and get it settled. So, two options for people to show support for. One is to keep everything and get cute with the naming:: urlparse -> url.parse urllib -> url.fetch urllib2 -> url.request The second option is to ditch urllib, move the handy quoting tools into either their own module or into what is currently urllib2:: urlparse -> url.parse urllib -> GONE urllib's utility functions -> url.quote urllib2 -> url.request So, if you have an opinion please speak up! -Brett From fumanchu at aminus.org Fri Feb 29 02:07:02 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Thu, 28 Feb 2008 17:07:02 -0800 Subject: [Web-SIG] Choosing one of two options for url* in the stdlib reorg In-Reply-To: References: Message-ID: Brett Cannon wrote: > With PyCon approaching and having other stuff on my plate to deal with > I want to try to reach a consensus on the whole > urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0 > and get it settled. > > So, two options for people to show support for. One is to keep > everything and get cute with the naming:: > > urlparse -> url.parse > urllib -> url.fetch > urllib2 -> url.request > > The second option is to ditch urllib, move the handy quoting tools > into either their own module or into what is currently urllib2:: > > urlparse -> url.parse > urllib -> GONE > urllib's utility functions -> url.quote > urllib2 -> url.request +0.5 for this second option. But what will happen to all the other names urllib2 currently imports from urllib that aren't "quotey"? from urllib import (unwrap, unquote, splittype, splithost, addinfourl, splitport, splitgophertype, splitquery, splitattr, ftpwrapper, noheaders, splituser, splitpasswd, splitvalue) I wouldn't mind if "urllib's utility functions" just moved into url.parse. Then we'd have one module for parsing (and unparsing) URL's and one for actually using them. Robert Brewer fumanchu at aminus.org From brett at python.org Fri Feb 29 02:15:52 2008 From: brett at python.org (Brett Cannon) Date: Thu, 28 Feb 2008 17:15:52 -0800 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg In-Reply-To: <20080228195636.AHU13046@ms19.lnh.mail.rcn.net> References: <20080228195636.AHU13046@ms19.lnh.mail.rcn.net> Message-ID: On Thu, Feb 28, 2008 at 4:56 PM, Raymond Hettinger wrote: > I'm inclined towards the fancy naming option. Ditching the most commonly used module in the standard library doesn't seem like progress to me. The thing that seems to bug people is choosing between urllib and urllib2 without knowing how they differ. The question is whether most of urllib's usage is simple and through urlopen(), in which case most code can just use urllib2's implementation seamlessly. In which case urllib is just code that is unneeded and taking up developer cycles to maintain. Plus having it removed from the stdlib does not mean it won't still be available. Anything removed from the stdlib can easily be made as an external download that is 3.0 compatible that people can drop in to use until they have time to transition over to what is now urllib2. If urllib doesn't go between 2.x and 3.0 I will push to have it deprecated at some point in 3.x life cycle. I would rather have the module made an external download at transition time instead of having to continue to maintain it in both 2.x and 3.x for any great length of time. But since I don't have answers to everything I am asking here. =) -Brett From brett at python.org Fri Feb 29 02:17:24 2008 From: brett at python.org (Brett Cannon) Date: Thu, 28 Feb 2008 17:17:24 -0800 Subject: [Web-SIG] Choosing one of two options for url* in the stdlib reorg In-Reply-To: References: Message-ID: On Thu, Feb 28, 2008 at 5:07 PM, Robert Brewer wrote: > Brett Cannon wrote: > > With PyCon approaching and having other stuff on my plate to deal with > > I want to try to reach a consensus on the whole > > urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0 > > and get it settled. > > > > So, two options for people to show support for. One is to keep > > everything and get cute with the naming:: > > > > urlparse -> url.parse > > urllib -> url.fetch > > urllib2 -> url.request > > > > The second option is to ditch urllib, move the handy quoting tools > > into either their own module or into what is currently urllib2:: > > > > urlparse -> url.parse > > urllib -> GONE > > urllib's utility functions -> url.quote > > urllib2 -> url.request > > +0.5 for this second option. But what will happen to all the other names > urllib2 currently imports from urllib that aren't "quotey"? > > from urllib import (unwrap, unquote, splittype, splithost, > addinfourl, splitport, splitgophertype, splitquery, > splitattr, ftpwrapper, noheaders, splituser, splitpasswd, > splitvalue) > It can be moved to where ever it needs to go. Anything that is not publicly exposed can just stay hidden. Otherwise it just shifts to one of the modules in the package. > I wouldn't mind if "urllib's utility functions" just moved into > url.parse. Then we'd have one module for parsing (and unparsing) URL's > and one for actually using them. > Having only url.parse and url.request is fine by me. The real question is whether urllib needs to stay 3.0 or not. Once that is decided organizing the merge can begin. -Brett From brett at python.org Fri Feb 29 02:24:26 2008 From: brett at python.org (Brett Cannon) Date: Thu, 28 Feb 2008 17:24:26 -0800 Subject: [Web-SIG] Cookie, cookielib; what to do? Message-ID: When I brought this up last it was when I first began bombarding this list with stdlib reorganization questions, so there was some noise about the whole process and no clear resolution was reached. The problem is that both modules have a Cookie class, so they can be merged. Much like the url* issue, one option is keeping both, although no great names came up. The whole cookie.client cookie.server didn't seem to win people over. Maybe cookie.client and cookie.parsing? The other option is to drop Cookie for cookielib, but people didn't seem to love that idea, so I am not pushing hard for that as their uses don't overlap very well (if I am wrong, please correct me). And I am not willing to count on a merger of functionality into cookielib in time for 3.0's release. So my question is what do people see as a possible naming scheme for these modules? Cookie has to be renamed because of its PEP 8 violation. Here are some ideas:: cookielib -> cookielib Cookie -> cookielib2 (with plans to move what needs to go from Cookie into cookielib at some point and to deprecate cookielib2 in 3.x). cookielib -> http.cookies Cookie -> http.cookies2 (same thinking as above). cookielib -> cookies.client Cookie -> cookies.parsing Any input on this would be great. From fumanchu at aminus.org Fri Feb 29 02:31:57 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Thu, 28 Feb 2008 17:31:57 -0800 Subject: [Web-SIG] Cookie, cookielib; what to do? In-Reply-To: References: Message-ID: Brett Cannon wrote: > So my question is what do people see as a possible naming scheme for > these modules? Cookie has to be renamed because of its PEP 8 > violation. Here are some ideas:: > > cookielib -> cookielib > Cookie -> cookielib2 (with plans to move what needs to go from Cookie > into cookielib at some point and to deprecate cookielib2 in 3.x). > > cookielib -> http.cookies > Cookie -> http.cookies2 (same thinking as above). > > cookielib -> cookies.client > Cookie -> cookies.parsing I'd propose: Cookie -> http.cookies cookielib -> http.cookiejar Robert Brewer fumanchu at aminus.org From brett at python.org Fri Feb 29 02:46:32 2008 From: brett at python.org (Brett Cannon) Date: Thu, 28 Feb 2008 17:46:32 -0800 Subject: [Web-SIG] Cookie, cookielib; what to do? In-Reply-To: References: Message-ID: On Thu, Feb 28, 2008 at 5:31 PM, Robert Brewer wrote: > Brett Cannon wrote: > > So my question is what do people see as a possible naming scheme for > > these modules? Cookie has to be renamed because of its PEP 8 > > violation. Here are some ideas:: > > > > cookielib -> cookielib > > Cookie -> cookielib2 (with plans to move what needs to go from Cookie > > into cookielib at some point and to deprecate cookielib2 in 3.x). > > > > cookielib -> http.cookies > > Cookie -> http.cookies2 (same thinking as above). > > > > cookielib -> cookies.client > > Cookie -> cookies.parsing > > I'd propose: > > Cookie -> http.cookies > cookielib -> http.cookiejar +1 from me. -Brett From fdrake at gmail.com Fri Feb 29 07:26:58 2008 From: fdrake at gmail.com (Fred Drake) Date: Fri, 29 Feb 2008 01:26:58 -0500 Subject: [Web-SIG] Cookie, cookielib; what to do? In-Reply-To: References: Message-ID: <9cee7ab80802282226g11235232vae3f3dd8a3ebf632@mail.gmail.com> On Thu, Feb 28, 2008 at 5:31 PM, Robert Brewer wrote: > I'd propose: > > Cookie -> http.cookies > cookielib -> http.cookiejar On Thu, Feb 28, 2008 at 8:46 PM, Brett Cannon wrote: > +1 from me. And +1 from me as well. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller From brett at python.org Fri Feb 29 20:20:19 2008 From: brett at python.org (Brett Cannon) Date: Fri, 29 Feb 2008 11:20:19 -0800 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg In-Reply-To: <47C7DE17.4050606@egenix.com> References: <47C7DE17.4050606@egenix.com> Message-ID: On Fri, Feb 29, 2008 at 2:27 AM, M.-A. Lemburg wrote: > > On 2008-02-29 01:47, Brett Cannon wrote: > > [BCC'ing stdlib-sig and web-sig so that both vote but that I don't > > have to clear a bunch of replies in the stdlib-sig mailing list from > > people not on both lists =) ] > > > > With PyCon approaching and having other stuff on my plate to deal with > > I want to try to reach a consensus on the whole > > urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0 > > and get it settled. > > > > So, two options for people to show support for. One is to keep > > everything and get cute with the naming:: > > > > urlparse -> url.parse > > urllib -> url.fetch > > urllib2 -> url.request > > > > The second option is to ditch urllib, move the handy quoting tools > > into either their own module or into what is currently urllib2:: > > > > urlparse -> url.parse > > urllib -> GONE > > urllib's utility functions -> url.quote > > urllib2 -> url.request > > > > So, if you have an opinion please speak up! > > urllib and urllib2 use rather different approaches to extending. > urllib needs to be subclassed, while urllib2 uses handlers that > you can plug in to get different functionality. > > I don't see how you could easily move code using one approach > to then use the other in Py3k. > > As for usage, urllib is by far more used than urllib2 (just check > Google Code Search to get an idea). > > Then again, most use of urllib is probably just calling > urllib.urlopen() and not doing any of the fancy stuff like > adding extra error handling. If urllib2's urlopen() works in > the same way as urllib.urlopen(), the move would be easy > for this use case. > The main difference is urllib.urlopen() has a proxies argument and urllib2.urlopen() has a timeout option. Otherwise the interface on the returned object, best I can tell, is the same. > For the second common use of subclassing urllib.URLopener > or urllib.FancyURLopener, removing urllib altogether would > mean having to rewrite the code to use the different > handler approach in urllib2. > Not necessarily. As has been stated, urllib can be released as an external library for people who want to use that instead of shift over to urllib2. That way the stdlib gets cleaner without forcing people to have to retool their code in order to keep using old libraries. > However, this is not necessary if we copy over the two > classes to url.request. > > So, I'd be +1 on the second approach, provided that those > two classes make the transition into url.request as > well. Otherwise, I'm +1 on the first approach and -1 > on the second. > Just to make sure I got this straight, as long as the two classes without the urllib._urlopener support from urlopen() are moved forward you are happy with this? What about making urllib an external library people can download and install using distutils? -Brett From brett at python.org Fri Feb 29 23:21:29 2008 From: brett at python.org (Brett Cannon) Date: Fri, 29 Feb 2008 14:21:29 -0800 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg In-Reply-To: <47C86270.9070605@egenix.com> References: <47C7DE17.4050606@egenix.com> <47C86270.9070605@egenix.com> Message-ID: On Fri, Feb 29, 2008 at 11:52 AM, M.-A. Lemburg wrote: > On 2008-02-29 20:20, Brett Cannon wrote: > >> So, I'd be +1 on the second approach, provided that those > >> two classes make the transition into url.request as > >> well. Otherwise, I'm +1 on the first approach and -1 > >> on the second. > >> > > > > Just to make sure I got this straight, as long as the two classes > > without the urllib._urlopener support from urlopen() are moved forward > > you are happy with this? > > Yes. > > > > What about making urllib an external library people can download and > > install using distutils? > > Well, removing urllib from the std lib doesn't mean that the module > is gone, but that's true for most modules in the std lib, right ? > > The key argument for doing the std lib reorg - as I understand it - > was to be able to have a 2to3.py take care of changing the imports > in a script to make it work on 3.x. > Yes, as well as to clean out the cruft in the stdlib. > If you're now suggesting to move modules out of the way with no > option to automatically port them to 3.x, then you're going far > beyond that original intent. > No, the modules are already ported to 3.0. This has been done all along in order for the test suite in Python to continue to work. Making them external just means that if you want to use it in Python 3.0 you need to download the source and run the included setup.py to install the module. Then 2to3 doesn't have to change anything as the original urllib imports can just import the copy downloaded and installed into site-packages. The only thing people would have to contend with is a Py3KWarning stating that the module has been removed from the stdlib but available for download from PyPI. > My main argument for keeping urllib logic in place is current > use of that module. Right, which is why I asked if people thought the current usage was small enough in terms of using things other than urlopen() that it would be okay to pull it out. And giving people the option to download and install a 3.0-compliant version would fill in the gap for anyone else who still wants the code. > If you look at Google code search (which only > scans OSS software and not even all of it), you get: > > import urllib -urllib.py -test_urllib -urllib2 > 28,800 matches > > + urllib.URLopener -FancyURLopener > 300 matches > > + urllib.FancyURLopener > 700 matches > > compared to: > > import urllib2 -urllib2.py -test_urllib2 > 10,700 matches > > + urllib2.Opener > 300 matches > > If you compare those results to searches for other modules > in the std lib, you'll find that those figures are high up > on the scale. Right, but how many of those urlopen() calls are just urlopen("some url"), which has a practical drop-in replacement from urllib2. -Brett From electronixtar at gmail.com Mon Feb 18 13:34:27 2008 From: electronixtar at gmail.com (est) Date: Mon, 18 Feb 2008 12:34:27 -0000 Subject: [Web-SIG] Could WSGI handle Asynchronous response? Message-ID: <6c3c7df3-4ad3-4917-853c-b40050a6a7da@h11g2000prf.googlegroups.com> I am writing a small 'comet'-like app using flup, something like this: def myapp(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return ['Flup works!\n'] <-------------Could this be part of response output? Could I time.sleep() for a while then write other outputs? if __name__ == '__main__': from flup.server.fcgi import WSGIServer WSGIServer(myapp, multiplexed=True, bindAddress=('0.0.0.0', 8888)).run() So is WSGI really synchronous? How can I handle asynchronous outputs with flup/WSGI ? From python at rcn.com Fri Feb 29 01:56:37 2008 From: python at rcn.com (Raymond Hettinger) Date: Fri, 29 Feb 2008 00:56:37 -0000 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg Message-ID: <20080228195636.AHU13046@ms19.lnh.mail.rcn.net> I'm inclined towards the fancy naming option. Ditching the most commonly used module in the standard library doesn't seem like progress to me. The thing that seems to bug people is choosing between urllib and urllib2 without knowing how they differ. Raymond From facundobatista at gmail.com Fri Feb 29 01:59:56 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Fri, 29 Feb 2008 00:59:56 -0000 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg In-Reply-To: References: Message-ID: 2008/2/28, Brett Cannon : > urlparse -> url.parse > urllib -> GONE > urllib's utility functions -> url.quote > urllib2 -> url.request +1, exactly what I had in mind. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From mal at egenix.com Fri Feb 29 11:27:36 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 29 Feb 2008 10:27:36 -0000 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg In-Reply-To: References: Message-ID: <47C7DE17.4050606@egenix.com> On 2008-02-29 01:47, Brett Cannon wrote: > [BCC'ing stdlib-sig and web-sig so that both vote but that I don't > have to clear a bunch of replies in the stdlib-sig mailing list from > people not on both lists =) ] > > With PyCon approaching and having other stuff on my plate to deal with > I want to try to reach a consensus on the whole > urllib/urllib2/urlparse situation for the stdlib reorg in Python 3.0 > and get it settled. > > So, two options for people to show support for. One is to keep > everything and get cute with the naming:: > > urlparse -> url.parse > urllib -> url.fetch > urllib2 -> url.request > > The second option is to ditch urllib, move the handy quoting tools > into either their own module or into what is currently urllib2:: > > urlparse -> url.parse > urllib -> GONE > urllib's utility functions -> url.quote > urllib2 -> url.request > > So, if you have an opinion please speak up! urllib and urllib2 use rather different approaches to extending. urllib needs to be subclassed, while urllib2 uses handlers that you can plug in to get different functionality. I don't see how you could easily move code using one approach to then use the other in Py3k. As for usage, urllib is by far more used than urllib2 (just check Google Code Search to get an idea). Then again, most use of urllib is probably just calling urllib.urlopen() and not doing any of the fancy stuff like adding extra error handling. If urllib2's urlopen() works in the same way as urllib.urlopen(), the move would be easy for this use case. For the second common use of subclassing urllib.URLopener or urllib.FancyURLopener, removing urllib altogether would mean having to rewrite the code to use the different handler approach in urllib2. However, this is not necessary if we copy over the two classes to url.request. So, I'd be +1 on the second approach, provided that those two classes make the transition into url.request as well. Otherwise, I'm +1 on the first approach and -1 on the second. Python just got off the ground for doing web programming, so making life hard for people using it in that application space is not a good idea. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 29 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 From mal at egenix.com Fri Feb 29 20:52:18 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 29 Feb 2008 19:52:18 -0000 Subject: [Web-SIG] [stdlib-sig] Choosing one of two options for url* in the stdlib reorg In-Reply-To: References: <47C7DE17.4050606@egenix.com> Message-ID: <47C86270.9070605@egenix.com> On 2008-02-29 20:20, Brett Cannon wrote: >> So, I'd be +1 on the second approach, provided that those >> two classes make the transition into url.request as >> well. Otherwise, I'm +1 on the first approach and -1 >> on the second. >> > > Just to make sure I got this straight, as long as the two classes > without the urllib._urlopener support from urlopen() are moved forward > you are happy with this? Yes. > What about making urllib an external library people can download and > install using distutils? Well, removing urllib from the std lib doesn't mean that the module is gone, but that's true for most modules in the std lib, right ? The key argument for doing the std lib reorg - as I understand it - was to be able to have a 2to3.py take care of changing the imports in a script to make it work on 3.x. If you're now suggesting to move modules out of the way with no option to automatically port them to 3.x, then you're going far beyond that original intent. My main argument for keeping urllib logic in place is current use of that module. If you look at Google code search (which only scans OSS software and not even all of it), you get: import urllib -urllib.py -test_urllib -urllib2 28,800 matches + urllib.URLopener -FancyURLopener 300 matches + urllib.FancyURLopener 700 matches compared to: import urllib2 -urllib2.py -test_urllib2 10,700 matches + urllib2.Opener 300 matches If you compare those results to searches for other modules in the std lib, you'll find that those figures are high up on the scale. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 29 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