Re: [Web-SIG] Announcing bobo
Hey all, I think we can pretty safely ignore Etienne as either a troll or an unnecessarily rude person. Has anyone looked at Bobo yet? I'd be interested in comparisons between it and Quixote, which is what I've mostly used in the past. I believe that Bobo begat Zope, which begat Quixote as (I thought) an attempt to return to Bobo-style programming, and so I'm curious about what sort of choices Bobo has made. thanks, --titus -- C. Titus Brown, c...@msu.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Time a for JSON parser in the standard library?
On Mon, Mar 10, 2008 at 11:55:04PM -0500, Massimo Di Pierro wrote: - It would also be nice to have a common interface to all modules that - do serialization. For example pickle, cPickle, marshall has dumps, so - json should also have dumps. Doesn't it? Or did you want something additional? http://svn.red-bean.com/bob/simplejson/tags/simplejson-1.7/docs/index.html --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Dealing with urllib, urllib2, and urlparse
On Wed, Feb 20, 2008 at 09:38:16PM -0500, Fred Drake wrote: - On Wed, Feb 20, 2008 at 8:57 PM, Bill Janssen [EMAIL PROTECTED] 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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] about WSGI adoption
On Sun, Nov 18, 2007 at 09:03:23PM +0100, Manlio Perillo wrote: - Titus Brown ha scritto: - - - - However I still consider remarkable that there is not a trac.wsgi script. - - Can this be caused by the lack of a standardized deployment of WSGI - - applications? - - What would a trac.wsgi script contain? - - import trac.web.main - - application = trac.web.main.dispatch_request So this is something that can be 'execfile'd, I guess... - WSGI is a programming interface, - not a script interface like CGI. - - Right, but a WSGI server/gateway just needs a simple script to execute - the WSGI application. That might be useful for some WSGI deployment techniques and less useful for others. For example, if you're using an SCGI-based WSGI server, you need a command-line executable; for mod_python, you probably need an importable module with a function; for CGI, you need a CGI script; etc. So I think you're talking about something that is very specific to your own deployment technique. This is out of the scope of the WSGI proposal, for good reasons -- there are many ways of configuring and deploying WSGI apps and I don't know that we've settled on only one way. Paste is an effort to standardize deployment of WSGI applications, I think. cheers, --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] The web dudes pad is open for business
now doesn't everyone wish they were at PyCon, too? ;) On Fri, Feb 23, 2007 at 08:06:48AM -0500, Chad Whitacre wrote: - The jacuzzi's open, too, if you brought trunks. - - We have a jacuzzi!? Please tell me it's not heart-shaped ... - - You guys have fun today, I don't get in until tonight. :^( - - - - chad - ___ - Web-SIG mailing list - Web-SIG@python.org - Web SIG: http://www.python.org/sigs/web-sig - Unsubscribe: http://mail.python.org/mailman/options/web-sig/titus%40caltech.edu - ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] wsgiref and wsgi.multithread/wsgi.multiprocess
Hi folks, I just ran into an interesting sanity check problem, and I was hoping you could all cross-check *my* sanity. Should the WSGI environ variables 'wsgi.multithread' and 'wsgi.multiprocess' be set to 'True' in wsgiref.simple_server.WSGIServer? They are, currently, but I see no indication in WSGIServer (inheriting from BaseHTTPServer.HTTPServer) of multithreadedness or multiprocessedness. thanks, --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref and wsgi.multithread/wsgi.multiprocess
On Fri, Feb 09, 2007 at 12:10:00PM -0500, Phillip J. Eby wrote: - At 11:54 PM 2/8/2007 -0800, Titus Brown wrote: - Hi folks, - - I just ran into an interesting sanity check problem, and I was hoping - you could all cross-check *my* sanity. - - Should the WSGI environ variables 'wsgi.multithread' and - 'wsgi.multiprocess' be set to 'True' in - wsgiref.simple_server.WSGIServer? - - They are, currently, but I see no indication in WSGIServer - (inheriting from BaseHTTPServer.HTTPServer) of multithreadedness - or multiprocessedness. - - Yeah, multiprocess should probably be set false there, and - multithreadedness should depend on whether the ThreadingTCPServer or - whatever it's called is mixed in. (HTTPServer does in fact support this, - but it's not tested in a WSGI context as far as I know.) OK. Err, do you want a patch? ;) The problem I'm running into is that our (Mike Orr I) WSGI interface for Quixote does a check to make sure that the Quixote application is explicitly marked as threadsafe before allowing a multithreaded WSGI server to run it. I can't bring myself to remove this sanity check, because it does seem like a good idea, but it makes the example code a bit more complicated... --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] 'scotch' WSGI recording proxy.
Hi folks, here's a project I've been working on: http://issola.caltech.edu/~t/scotch/doc/ 'scotch' currently consists of two modules, WSGI recording middleware and a WSGI proxy application. See the docs above for some minimal information. You can grab it via darcs at darcs.idyll.org/~t/projects/scotch/ or in a tarball at http://darcs.idyll.org/~t/projects/scotch-latest.tar.gz I posted a long blithering blog entry about this today here: http://www.advogato.org/person/titus/diary.html?start=177 (at the bottom). I'm interested in comments, thoughts, criticisms, etc... right now it's rather immature, and I'm hoping to get some insight into where it should go from your comments. cheers, --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] [Fwd: Summer of Code preparation]
On Mon, Apr 17, 2006 at 10:39:59AM -0500, Ian Bicking wrote: - Hi guys... looks like Google SoC is back on again. I'm hoping we get - some good web stuff going on, so people should start thinking. Also - there's two wiki pages where you can add project ideas: - http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date - (and needs cleaning) page from last year: - http://wiki.python.org/moin/CodingProjectIdeas I'm thinking of proposing a project to build a JavaScript interpreter interface for Python; the goal (for me) is to get twill/mechanize to understand JavaScript. I think the project has wider applications, but I'm not sure what people actually want to do with JavaScript. I could imagine server-side parsing of javascript, and/or integration of javascript and python code. Thoughts? --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] [Fwd: Summer of Code preparation]
On Mon, Apr 17, 2006 at 11:47:12AM -0500, Ian Bicking wrote: - Titus Brown wrote: - On Mon, Apr 17, 2006 at 10:39:59AM -0500, Ian Bicking wrote: - - Hi guys... looks like Google SoC is back on again. I'm hoping we get - - some good web stuff going on, so people should start thinking. Also - - there's two wiki pages where you can add project ideas: - - http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date - - (and needs cleaning) page from last year: - - http://wiki.python.org/moin/CodingProjectIdeas - - I'm thinking of proposing a project to build a JavaScript interpreter - interface for Python; the goal (for me) is to get twill/mechanize to - understand JavaScript. I think the project has wider applications, - but I'm not sure what people actually want to do with JavaScript. - I could imagine server-side parsing of javascript, and/or integration of - javascript and python code. Thoughts? - - Do you mean like integrating Mozilla's Spidermonkey with Python? That - would be a very approachable and useful project, I think. It even gets - us a restricted execution environment ;) Yes, something like this. Personally I'd be happy to get good twill/mechanize integration, but methinks a complete wrapper that is then hooked into twill/mechanize is the proper way to go. Then it would be of use to others. - I'm personally non-plussed by deeper integration, like parsing - Javascript in Python or otherwise mingling the runtimes. But I know - other people find the idea of that sort of thing much more appealing - than I do. Regardless of motivation, I think the simpler Spidermonkey - integration would be more useful *and* much easier. Definitely an - interesting idea -- and the more I think about the restricted execution - aspect, the more plausibly useful that sounds. (Rich templating - languages using Javascript?) - - I think Brett Cannon is doing something specifically related to Python - and Javascript for his doctorate, though what exactly that entails is a - little less clear to me -- I think it's more related to Python in the - browser, which is kind of the flip side of this. I'll look into it, thanks! --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Standalone WSGI form framework.
- I'm looking for a framework-independent form library. I'm using the - Quixote forms library at the moment, inside my own framework, but - would ideally like something more WSGI oriented, so that it is easier - to mock and unittest. hi, Alan, I'm confused by this -- this could mean that you want to separate the quixote forms lib from the Quixote 'request' object, I guess. What else? In any case, please let me (or the list) know if you find something that matches all of your requirements. Apart from the WSGI aspect, the quixote forms lib has #1, #2, #5, and I think #6. It does also attempt to generate HTML, but you can always just not call the render() functions, right? ;) It might be relatively easy to add the features to the quixote forms lib, too... thanks, --titus - My ideal form framework should do the following - - 1. Parsing of submitted POST requests, etc - 2. Binding of incoming form variables to the attributes of a target - python data object - 3. Customisable validation, with management of validation error messages. - 4. Generate unique (hierarchical) field names for sub-attributes of - the data object to be edited, which are javascript-identifier-safe, - i.e. can be used as the names of HTML form input elements. - 5. Handle multipart/form-data - 6. Nice-to-have: transparently handle multi-page forms, e.g. hub forms, etc. - - It should NOT - - 1. Attempt to generate HTML, or be tied to a specific templating mechanism ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] [twill] ANNOUNCE: twill v0.8
ANNOUNCING twill v0.8. twill is a simple language for testing Web applications. It's designed for automated testing of Web sites, but it can be used to interact with Web sites in a variety of ways. twill has an interactive shell, 'twill-sh', and can also run scripts. twill is a reimplementation of Cory Dodt's PBP. It is built on top of Python and John J. Lee's mechanize. A twill script looks like this: # go to the /. login page go http://slashdot.org/login.pl # fill in the form fv 1 unickname test fv 1 upasswd test submit # ok, there's no such account ;). show error HTML. show --- This is the sixth public release of twill, version 0.8. (Tagline: 85% unit tested.) You can install twill with easy_install via PyPi, or download the latest .tar.gz at: http://darcs.idyll.org/~t/projects/twill-0.8.tar.gz Documentation is included in the .tar.gz and is also online at http://www.idyll.org/~t/www-tools/twill.html --- Miscellaneous details: twill is implemented in Python and uses pyparsing and mechanize. In addition to the existing simple command language, twill can easily be extended with Python. twill also provides a fairly simple and well-documented wrapper around mechanize. twill scripts can be recorded with maxq, although scripts may require some hand tweaking at the moment. See the twill documentation for more information. twill does not understand JavaScript, I'm sorry to say. --- New features: * test WSGI Python applications in-process; * Updated to latest versions of mechanize, ClientCookie, ClientForm, and pullparser; * Significant increase in number of unit tests their code coverage; * Automatic 'tidy' preprocessing when available; * easy_install/eggs now supported; * http-equiv redirect now works; * new commands: - 'formaction' changes form URLs; - 'tidy_ok' checks for 'tidy' correctness; - 'showhistory' command; Special thanks to sureshvv and Simon Buenzli... ___ twill mailing list twill@lists.idyll.org http://lists.idyll.org/listinfo/twill ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Global Variables
- I second the statement about multi-threading headaches if you use - globals in this way. - - In Aquarium, since I have to support different threading API's (no - threads, Python threads, coroutines), I put everything in a Context - object, and then pass that Context object to everything's constructor. - This isn't as bad as it sounds. It happens automatically when I call - aquariumFactory(moduleName, *args, **kargs) which does a dynamic - import, instantiates the class passing the Context object and the - additional args, and then returns the instance. You can also write a function to get the variable, _global_var = None def init_global_var(): global _global_var _global_var = GlobalSomethingOrOther() def get_global_var(): return _global_var Then in the case of multithreaded apps, you can change these functions to use a dictionary of global variables indexed by thread-id. --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI middleware library
- What do people think about collaborating on a kind of standard library - of WSGI middleware? Hi, Ian, ok, here's another response ;). I slept on it a bit, and I would like to suggest one modification: make it a cookbook of examples, rather than a library. This implies that we don't need to have a standard naming scheme or a common coding style to the components, and there can be redundancy -- multiple examples overlapping in functionality. It also means that there is room for incomplete solutions, which are IMO of great value even just as stubs. Such code can be isolated and used piecemeal, independently of the rest of the library. And, finally, it means that code can be designed strictly for functionality rather than for extensibility. I make this suggestion for two reasons: first of all, I'd be more interested in contributing code to a cookbook than to a library, for the above reasons. And, secondly, my limited experience with example code I've posted suggests that people are primarily interested in a complete, functioning example that's isolated from other code. I do think a test harness (to make sure that the middleware is WSGI compliant) and a documentation standard (reST? In each directory? or ...?) would be a good idea. As immediate candidates for inclusion I suggest: * a simple wsgi-passthrough middleware, that handles the data without modifying it. (The idea is to provide hooks where I/O *can* be modified.) Most of my time in wsgiComment was spent figuring out how to get that functionality. * the CGI server from the PEP. I can submit nicely formatted versions of these if you're interested in proceeding immediately; I'd also be happy to host a Darcs repository for the stuff ;). cheers, --titus ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
