From stephan at transvection.de Wed Sep 10 14:54:45 2008 From: stephan at transvection.de (Stephan Diehl) Date: Wed, 10 Sep 2008 14:54:45 +0200 Subject: [Web-SIG] wsgi.org server Message-ID: <48C7C395.4010402@transvection.de> Hi, I've just upgraded the wsgi.org server to moin 1.7.2 and a mod_wsgi adapter. Please tell me, if there's any problem. Has somebody a good idea for a 'wsgi' or 'wsgi powered' logo? I'd really like to make the look a bit nicer, but my own design skills are not that good... any ideas welcome. Stephan -- Stephan Diehl, transvection, Programmierung und Beratung Oranienplatz 5, 10999 Berlin, mob - 0151/22844655 tel - 030/62727703, web - http://transvection.de From noah.gift at gmail.com Wed Sep 10 20:08:06 2008 From: noah.gift at gmail.com (Noah Gift) Date: Wed, 10 Sep 2008 14:08:06 -0400 Subject: [Web-SIG] wsgi.org server In-Reply-To: <48C7C395.4010402@transvection.de> References: <48C7C395.4010402@transvection.de> Message-ID: On Wed, Sep 10, 2008 at 8:54 AM, Stephan Diehl wrote: > Hi, > > I've just upgraded the wsgi.org server to moin 1.7.2 and a mod_wsgi adapter. > Please tell me, if there's any problem. > Has somebody a good idea for a 'wsgi' or 'wsgi powered' logo? I think something with tentacles or tubes or pipes. You might try outsourcing the logo design to guru.com or elance. I'd really > like to make the look a bit nicer, but my own design skills are not that > good... any ideas welcome. > > Stephan > -- > Stephan Diehl, transvection, Programmierung und Beratung > Oranienplatz 5, 10999 Berlin, mob - 0151/22844655 > tel - 030/62727703, web - http://transvection.de > _______________________________________________ > 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/noah.gift%40gmail.com > -- Noah Gift http://noahgift.com From manlio_perillo at libero.it Wed Sep 10 20:02:04 2008 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed, 10 Sep 2008 20:02:04 +0200 Subject: [Web-SIG] a new implementation of multipart/form-data parser Message-ID: <48C80B9C.2010201@libero.it> Hi all. For my WSGI framework I have implemented a multipart/form-data parser. http://hg.mperillo.ath.cx/wsgix/diff/70aacc4a8301/wsgix/parse.py The code has been adapted from cgi.parse_multidata. I think that the function is more robust of FieldStorage, since you can set a max size for field data stored in memory. The code is more simple, too (since I have done a little review of current browsers behaviour, and none of them use multipart/mixed when encoding multiple file fields with the same name). Now I'm going to write a middleware that takes a POST request with data encoded in multipart/form-data, and transcode the request entity in application/www-form-urlencoded, with file fields saved as: field_name=&field_path=&field_content_type= where is the temporary path where the file has been stored. Note that there is a Nginx module http://www.grid.net.ru/nginx/upload.en.html that does this (but don't transcode in application/www-form-urlencoded. Any one interested? I really whould like some reviews. Thanks Manlio Perillo From dirk.holtwick at gmail.com Wed Sep 10 20:21:31 2008 From: dirk.holtwick at gmail.com (Dirk Holtwick) Date: Wed, 10 Sep 2008 20:21:31 +0200 Subject: [Web-SIG] Keg - A python web framework In-Reply-To: <3e371780808031457l75a10f51h883e1d96cca2943a@mail.gmail.com> References: <3e371780808031457l75a10f51h883e1d96cca2943a@mail.gmail.com> Message-ID: <48C8102B.60600@gmail.com> Hi, maybe you'd like to have a look at just another Python framework that I'm writing ;) It seems that the goals you describe fit mine too. The project home is here: http://code.google.com/p/pyxer/ You get the best impression of what it is all about if you check out the SVN repository and have a look into "docs/pyxer.html" and the "examples" folder. Here is the SVN: svn checkout http://pyxer.googlecode.com/svn/trunk/ pyxer-read-only But in two words writing a Hello World controller is as simple as: @controller def index(): return "Hello World" This is the result of some programming conventions, but they may all be changed and extended if needed. I think this makes the learning curve quite flat. Maybe you or someone else on this list is interested contributing? Thanks Dirk P.S.: This framework is far from being complete... eghansah schrieb: > Hi, > > I've been working on a python web framework which I think might be of > interest to you. > Details may be found at http://code.google.com/p/keg/wiki/Concept. > > > All suggestions or comments will be greatly appreciated. > > > Thank you. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/dirk.holtwick%40gmail.com From and-py at doxdesk.com Wed Sep 10 20:18:41 2008 From: and-py at doxdesk.com (Andrew Clover) Date: Wed, 10 Sep 2008 20:18:41 +0200 Subject: [Web-SIG] problem with wsgiref.util.request_uri and decoded uri In-Reply-To: <48873607.3030307@libero.it> References: <48873607.3030307@libero.it> Message-ID: <48C80F81.9080805@doxdesk.com> Manlio Perillo wrote: > On the other hand, if the WSGI gateway *do* decode the uri, > I can no more handle '/' in uri. Correct. CGI requires that '%2F' is decoded, and hence indistinguishable from '/' when it gets to the application. And WSGI inherits CGI's flaws for compatibility. request_uri is doing the right thing in assuming that if you got a '%40' in your PATH_INFO, it must originally have been a '%2540'. It is an irritating limitation, but so far not irritating enough for an optional workaround to have made its way into non-CGI-based WSGI servers. It may become a bigger irritation as we move to Py3K, and get stuck with decoded top-bit-set characters being turned into Unicode using the system encoding (which is likely to be wrong). Windows already suffers from similar problems as its environment variables are natively Unicode, and its system encoding is never UTF-8 (which is the most likely encoding for path parts). > Where can I find informations about alternate encoding scheme? It's easy enough to roll your own. For example htmlform uses a scheme of encoding path parts to '+XX' instead of '%XX'. encode_re= re.compile('[^-_.!~*()\'0-9a-zA-Z]') decode_re= re.compile(r'\+([0-9a-zA-Z][0-9a-zA-Z])') def encode(s): return encode_re.sub(lambda m: '+%02X' % (ord(m.group())), s) def decode(s): decode_re.sub(lambda m: chr(int(m.group(1),16)), s) -- And Clover mailto:and at doxdesk.com http://www.doxdesk.com/ From manlio_perillo at libero.it Wed Sep 10 20:47:53 2008 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed, 10 Sep 2008 20:47:53 +0200 Subject: [Web-SIG] Async API for Python In-Reply-To: <4a038ea30808140711p13bf09c9j54c8fd0c958555c6@mail.gmail.com> References: <4a038ea30808140711p13bf09c9j54c8fd0c958555c6@mail.gmail.com> Message-ID: <48C81659.7000000@libero.it> Jerry Spicklemire ha scritto: > Sorry, if this turns up twice ... > > Phillip J. Eby wrote, on Tue Jul 29 03:21:18 CEST 2008: > > "There is no async API that's part of WSGI itself, and it's > unlikely there will ever be one unless there ends up > being an async API for Python as well." > > http://mail.python.org/pipermail/web-sig/2008-July/003547.html > > > Following up, perhaps this would be of interest: > > "New PEP proposal: C Micro-Threading" > > "This PEP adds micro-threading (or 'green threads') > at the C level so that micro-threading is built in and > can be used with very little coding effort at the python > level. > Personally I think that implementing a standard reactor in Python is bad. The Micro-Threading should just offer an API, like Twisted Deferred, generators and greenlets do; the reactor should be implemented separately. > [...] Manlio Perillo From chris at simplistix.co.uk Tue Sep 23 09:45:33 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 23 Sep 2008 08:45:33 +0100 Subject: [Web-SIG] a new implementation of multipart/form-data parser In-Reply-To: <48C80B9C.2010201@libero.it> References: <48C80B9C.2010201@libero.it> Message-ID: <48D89E9D.7010302@simplistix.co.uk> Manlio Perillo wrote: > Any one interested? > I really whould like some reviews. If it formed part of WebOb, I'd be interested... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From alain.poirier at net-ng.com Wed Sep 24 23:02:17 2008 From: alain.poirier at net-ng.com (Alain Poirier) Date: Wed, 24 Sep 2008 23:02:17 +0200 Subject: [Web-SIG] [ANN] Nagare component bases web framework with continuation Message-ID: <200809242302.17580.alain.poirier@net-ng.com> Hi all, I'm pleased to announce that the first (0.1.0) version of the Nagare web framework is released! To read about its features: http://www.nagare.org/trac/wiki/NagareFeatures Release info and download page: http://pypi.python.org/pypi/nagare/ Source and documentation is available at the website: http://www.nagare.org Mailing lists - the place to ask questions: http://groups.google.com/group/nagare-users About Nagare ============ Nagare is a components based framework: a Nagare application is a composition of interacting components each one with its own state and workflow kept on the server. Each component can have one or several views that are composed to generate the final web page. This enables the developers to reuse or write highly reusable components easily and quickly. Thanks to Stackless Python, Nagare is also a continuation-based web framework which enables to code a web application like a desktop application, with no need to split its control flow in a multitude of controllers and with the automatic handling of the back, fork and refresh actions from the browser. Its component model and use of the continuation come from the famous Seaside SmallTalk framework. Furthermore Nagare integrates the best tools and standard from the Python world. For example: - WSGI: binds the application to several possible publishers, - lxml: generates the DOM trees and brings to Nagare the full set of XML features (XSL, XPath, Schemas ...), - setuptools: installs, deploys and extends the Nagare framework and the Nagare applications too, - PEAK Rules: generic methods are heavily used in Nagare, to associate views to components, to define security rules, to translate Python code to Javascript ... - WebOb: for its Request and Response Objects. Enjoy! A. Poirier From bob at redivi.com Sat Sep 27 20:16:12 2008 From: bob at redivi.com (Bob Ippolito) Date: Sat, 27 Sep 2008 11:16:12 -0700 Subject: [Web-SIG] simplejson 2.0.0 released, much faster. Message-ID: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> I spent a fair amount of time this week profiling, benchmarking, and optimizing simplejson. simplejson 2.0.0 includes the following enhancements: http://pypi.python.org/pypi/simplejson * optimized Python encoding path * optimized Python decoding path * optimized C encoding path * optimized C decoding path * switched to sphinx docs (nearly the same as the json module in python 2.6) Even without the C speedups, it's several times faster. With the C speedups, it's WAY faster. I highly recommend that everyone update their frameworks to use the latest code. For the primary benchmark I was concerned with (some internal data structures that Mochi uses) encoding is about 4x faster than cPickle (!), and decoding is just a tiny bit slower. There's little excuse to use other libraries now. The fastest alternative I'm aware of is cjson 1.0.5, which is currently a little faster than simplejson 2.0.0 when decoding but is actually slower than simplejson 2.0.0 at encoding (the more important path for people vending web services). In both cases, simplejson provides more flexibility (e.g. the decoding object_hook), so a slight speed cost when decoding is probably to be expected. There aren't really any API breaking changes, but when decoding a str input it will return str objects instead of unicode if the str is all ASCII with no escaped characters. I'm not aware of any scenario other than doctests where this could be a problem. -bob From arnarbi at gmail.com Sat Sep 27 20:35:52 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Sat, 27 Sep 2008 20:35:52 +0200 Subject: [Web-SIG] simplejson 2.0.0 released, much faster. In-Reply-To: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> References: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> Message-ID: <28012bc60809271135y5530763bge00a340bbe11447d@mail.gmail.com> Hi Bob, On Sat, Sep 27, 2008 at 20:16, Bob Ippolito wrote: > Even without the C speedups, it's several times faster. With the C > speedups, it's WAY faster. I highly recommend that everyone update > their frameworks to use the latest code. Excellent stuff! > There aren't really any API breaking changes, but when decoding a str > input it will return str objects instead of unicode if the str is all > ASCII with no escaped characters. I'm not aware of any scenario other > than doctests where this could be a problem. Is it configurable to make it always decode to unicode? Did you make this change for performance? cheers, Arnar From bob at redivi.com Sat Sep 27 22:13:36 2008 From: bob at redivi.com (Bob Ippolito) Date: Sat, 27 Sep 2008 13:13:36 -0700 Subject: [Web-SIG] simplejson 2.0.0 released, much faster. In-Reply-To: <28012bc60809271135y5530763bge00a340bbe11447d@mail.gmail.com> References: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> <28012bc60809271135y5530763bge00a340bbe11447d@mail.gmail.com> Message-ID: <6a36e7290809271313r75e19516r638fc5b66ccc8d48@mail.gmail.com> On Sat, Sep 27, 2008 at 11:35 AM, Arnar Birgisson wrote: > Hi Bob, > > On Sat, Sep 27, 2008 at 20:16, Bob Ippolito wrote: >> Even without the C speedups, it's several times faster. With the C >> speedups, it's WAY faster. I highly recommend that everyone update >> their frameworks to use the latest code. > > Excellent stuff! > >> There aren't really any API breaking changes, but when decoding a str >> input it will return str objects instead of unicode if the str is all >> ASCII with no escaped characters. I'm not aware of any scenario other >> than doctests where this could be a problem. > > Is it configurable to make it always decode to unicode? Did you make > this change for performance? If you give it unicode input, it will decode to unicode. Basically it scans through the str until it finds non-ASCII, escape, or end quote. If it finds the end quote first it will just allocate a new string with exactly that day, which is super fast since it's just an alloc and copy. It will of course always decode everything containing non-ASCII characters or any escape sequences to unicode. It is not currently configurable. It was done for performance, but also does produce nicer looking repr output because you don't have so many 'u' characters to look at :) Given the way str works in Python 2.x it should not be an incompatible change except for doctests... and I guess code that explicitly checks for unicode and doesn't know what to do with str, but that would be weird. -bob From arnarbi at gmail.com Sat Sep 27 23:10:32 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Sat, 27 Sep 2008 23:10:32 +0200 Subject: [Web-SIG] simplejson 2.0.0 released, much faster. In-Reply-To: <6a36e7290809271313r75e19516r638fc5b66ccc8d48@mail.gmail.com> References: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> <28012bc60809271135y5530763bge00a340bbe11447d@mail.gmail.com> <6a36e7290809271313r75e19516r638fc5b66ccc8d48@mail.gmail.com> Message-ID: <28012bc60809271410w34732573i3cdaa0433a16152@mail.gmail.com> On Sat, Sep 27, 2008 at 22:13, Bob Ippolito wrote: > If you give it unicode input, it will decode to unicode. Basically it > scans through the str until it finds non-ASCII, escape, or end quote. > If it finds the end quote first it will just allocate a new string > with exactly that day, which is super fast since it's just an alloc > and copy. > > It will of course always decode everything containing non-ASCII > characters or any escape sequences to unicode. It is not currently > configurable. It was done for performance, but also does produce nicer > looking repr output because you don't have so many 'u' characters to > look at :) Given the way str works in Python 2.x it should not be an > incompatible change except for doctests... and I guess code that > explicitly checks for unicode and doesn't know what to do with str, > but that would be weird. The reason I asked was because I've had problems even with pure-ASCII strs when mixed with unicode objects in some DB-API drivers, working with filesystems on the OS-X and others. A "solution" was to have everything in unicode. Since that means the string given to simplejson to decode will be a unicode string anyways, so in that case there's no problem :) cheers, Arnar From bob at redivi.com Sat Sep 27 23:24:14 2008 From: bob at redivi.com (Bob Ippolito) Date: Sat, 27 Sep 2008 14:24:14 -0700 Subject: [Web-SIG] simplejson 2.0.0 released, much faster. In-Reply-To: <28012bc60809271410w34732573i3cdaa0433a16152@mail.gmail.com> References: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> <28012bc60809271135y5530763bge00a340bbe11447d@mail.gmail.com> <6a36e7290809271313r75e19516r638fc5b66ccc8d48@mail.gmail.com> <28012bc60809271410w34732573i3cdaa0433a16152@mail.gmail.com> Message-ID: <6a36e7290809271424y4073edb0v3055654e30918b48@mail.gmail.com> On Sat, Sep 27, 2008 at 2:10 PM, Arnar Birgisson wrote: > On Sat, Sep 27, 2008 at 22:13, Bob Ippolito wrote: >> If you give it unicode input, it will decode to unicode. Basically it >> scans through the str until it finds non-ASCII, escape, or end quote. >> If it finds the end quote first it will just allocate a new string >> with exactly that day, which is super fast since it's just an alloc >> and copy. >> >> It will of course always decode everything containing non-ASCII >> characters or any escape sequences to unicode. It is not currently >> configurable. It was done for performance, but also does produce nicer >> looking repr output because you don't have so many 'u' characters to >> look at :) Given the way str works in Python 2.x it should not be an >> incompatible change except for doctests... and I guess code that >> explicitly checks for unicode and doesn't know what to do with str, >> but that would be weird. > > The reason I asked was because I've had problems even with pure-ASCII > strs when mixed with unicode objects in some DB-API drivers, working > with filesystems on the OS-X and others. A "solution" was to have > everything in unicode. I've never seen a pure ASCII str cause problems. I've seen pure ASCII unicode cause problems in stupid ways though, because not all Python C code that handles text can handle unicode. Dumb stuff like this bites me all the time in Genshi templates (where all string literals are unicode): >>> datetime.datetime.now().strftime(u'%Y') Traceback (most recent call last): File "", line 1, in TypeError: strftime() argument 1 must be str, not unicode Any operation involving a str and unicode should up-convert to unicode, and regardless of the defaultencoding a pure ASCII str will properly get handled (at least in Python 2.5, I don't remember what 2.4 did)... e.g. ''.join(['', u'foo']) returns u'foo' > Since that means the string given to simplejson to decode will be a > unicode string anyways, so in that case there's no problem :) If you can prove that there is an actual problem I'm sure I can come up with a flag that would ensure unicode, but the implementation would probably be just translation of the input document to unicode before decoding ;) -bob From arnarbi at gmail.com Sat Sep 27 23:31:50 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Sat, 27 Sep 2008 23:31:50 +0200 Subject: [Web-SIG] simplejson 2.0.0 released, much faster. In-Reply-To: <6a36e7290809271424y4073edb0v3055654e30918b48@mail.gmail.com> References: <6a36e7290809271116v689862dbm4ebc4af6e1db040a@mail.gmail.com> <28012bc60809271135y5530763bge00a340bbe11447d@mail.gmail.com> <6a36e7290809271313r75e19516r638fc5b66ccc8d48@mail.gmail.com> <28012bc60809271410w34732573i3cdaa0433a16152@mail.gmail.com> <6a36e7290809271424y4073edb0v3055654e30918b48@mail.gmail.com> Message-ID: <28012bc60809271431v6893d0cw4ccc1abf9516e422@mail.gmail.com> On Sat, Sep 27, 2008 at 23:24, Bob Ippolito wrote: > On Sat, Sep 27, 2008 at 2:10 PM, Arnar Birgisson wrote: >> On Sat, Sep 27, 2008 at 22:13, Bob Ippolito wrote: >>> If you give it unicode input, it will decode to unicode. Basically it >>> scans through the str until it finds non-ASCII, escape, or end quote. >>> If it finds the end quote first it will just allocate a new string >>> with exactly that day, which is super fast since it's just an alloc >>> and copy. >>> >>> It will of course always decode everything containing non-ASCII >>> characters or any escape sequences to unicode. It is not currently >>> configurable. It was done for performance, but also does produce nicer >>> looking repr output because you don't have so many 'u' characters to >>> look at :) Given the way str works in Python 2.x it should not be an >>> incompatible change except for doctests... and I guess code that >>> explicitly checks for unicode and doesn't know what to do with str, >>> but that would be weird. >> >> The reason I asked was because I've had problems even with pure-ASCII >> strs when mixed with unicode objects in some DB-API drivers, working >> with filesystems on the OS-X and others. A "solution" was to have >> everything in unicode. > > I've never seen a pure ASCII str cause problems. I've seen pure ASCII > unicode cause problems in stupid ways though, because not all Python C > code that handles text can handle unicode. Dumb stuff like this bites > me all the time in Genshi templates (where all string literals are > unicode): > >>>> datetime.datetime.now().strftime(u'%Y') > Traceback (most recent call last): > File "", line 1, in > TypeError: strftime() argument 1 must be str, not unicode > > Any operation involving a str and unicode should up-convert to > unicode, and regardless of the defaultencoding a pure ASCII str will > properly get handled (at least in Python 2.5, I don't remember what > 2.4 did)... e.g. ''.join(['', u'foo']) returns u'foo' Right, I can't remember the exact details now - this was in my last job :) >> Since that means the string given to simplejson to decode will be a >> unicode string anyways, so in that case there's no problem :) > > If you can prove that there is an actual problem I'm sure I can come > up with a flag that would ensure unicode, but the implementation would > probably be just translation of the input document to unicode before > decoding ;) Well, don't worry about it :) cheers, Arnar