From ianb at colorstudy.com Mon Oct 3 07:37:48 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 03 Oct 2005 00:37:48 -0500 Subject: [Web-SIG] ANN: Paste Packages 0.3 Message-ID: <4340C3AC.4080107@colorstudy.com> I'm pleased to release the first official packaging of the Paste suite of tools. I'm starting at 0.3 -- less committal than 1.0, but more confident than 0.1... just right for now. Python Paste aims brings consistency to Python web development and web application installation, providing tools for both developers and system administrators. Paste includes these packages: Paste (Core): A set of tools for building web frameworks, built on WSGI. Paste Deploy: A configuration loader for composing WSGI applications into application instances (and implicitly a sort of application server). Paste Script: A pluggable script (paster) for application development, particularly web development. Paste WebKit: A reimplementation of the Webware API, implemented with the tools in Paste Core, the configuration of Paste Deploy, and the application setup of Paste Script. Wareweb: An alpha framework taking some of the ideas from WebKit, and presenting them in a simplified and more decoupled form. Locations --------- Websites: http://pythonpaste.org/ http://pythonpaste.org/deploy/ http://pythonpaste.org/script/ http://pythonpaste.org/webkit/ http://pythonpaste.org/wareweb/ Download: http://cheeseshop.python.org/pypi/Paste/ http://cheeseshop.python.org/pypi/PasteDeploy/ http://cheeseshop.python.org/pypi/PasteScript/ http://cheeseshop.python.org/pypi/PasteWebKit/ http://cheeseshop.python.org/pypi/Wareweb/ Discussion list: http://pythonpaste.org/community/mailing-list.html Blog (announcements): http://pythonpaste.org/news/ From jjinux at gmail.com Tue Oct 11 19:01:33 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Tue, 11 Oct 2005 10:01:33 -0700 Subject: [Web-SIG] a convenient way to deeply nest try/finally statements Message-ID: I'm posting this in the hope someone else will find it useful. If you want it, consider it in the public domain. """This is a convenient way to deeply nest try/finally statements.""" __docformat__ = "restructuredtext" # Created: Tue Oct 11 08:42:23 PDT 2005 # Author: Shannon -jj Behrens # Email: jjinux at users.sourceforge.net # # Copyright (c) Shannon -jj Behrens. All rights reserved. def tryFinally(lst): """This is a convenient way to deeply nest try/finally statements. It is appropriate for complicated resource initialization and destruction. For instance, if you have a list of 50 things that need to get intialized and later destructed via using try/finally (especially if you need to create the list dynamically) this function is appropriate. Given:: lst = [ ((f_enter_0, f_enter_0_args, f_enter_0_kargs), (f_exit_0, f_exit_0_args, f_exit_0_kargs)), ((f_enter_1, f_enter_1_args, f_enter_1_kargs), (f_exit_1, f_exit_1_args, f_exit_1_kargs)), ((f_enter_2, f_enter_2_args, f_enter_2_kargs), (f_exit_2, f_exit_2_args, f_exit_2_kargs)) ] Execute:: f_enter_0(*f_enter_0_args, **f_enter_0_kargs) try: f_enter_1(*f_enter_1_args, **f_enter_1_kargs) try: f_enter_2(*f_enter_2_args, **f_enter_2_kargs) try: pass finally: f_exit_2(*f_exit_2_args, **f_exit_2_kargs) finally: f_exit_1(*f_exit_1_args, **f_exit_1_kargs) finally: f_exit_0(*f_exit_0_args, **f_exit_0_kargs) lst See the example above. Note that you can leave out parts of the tuples by passing shorter tuples. For instance, here are two examples:: # Second tuple missing. ((f_enter_2, f_enter_2_args, f_enter_2_kargs),) # Leave out args or args and kargs. ((f_enter_2,), (f_exit_2, f_exit_2_args)) """ def castTwoParts(first): lenFirst = len(first) default = ((), ()) max = len(default) if lenFirst > max: raise ValueError("""\ The lst must be a list of tuples of the form (enterTuple, exitTuple).""", first) return first + default[lenFirst:] def doNothing(*args, **kargs): pass def castFunctionArgsKargs(fTuple): lenFTuple = len(fTuple) default = (doNothing, (), {}) max = len(default) if lenFTuple > max: raise ValueError("""\ Each tuple in the lst is a pair of tuples that look like (f, args, kargs).""", fTuple) return fTuple + default[lenFTuple:] if not len(lst): return first, others = lst[0], lst[1:] first = castTwoParts(first) first = (castFunctionArgsKargs(first[0]), castFunctionArgsKargs(first[1])) ((fEnter, fEnterArgs, fEnterKargs), (fExit, fExitArgs, fExitKargs)) = first fEnter(*fEnterArgs, **fEnterKargs) try: tryFinally(others) finally: fExit(*fExitArgs, **fExitKargs) if __name__ == '__main__': from cStringIO import StringIO def printEverything(*args, **kargs): print >>buf, `args`, `kargs` def refuseArgs(): print >>buf, "refused args" lst = [ ((printEverything, ("f_enter_0_args",), {"in": "in"}), (printEverything, ("f_exit_0_args",))), ((printEverything,), ()), ((refuseArgs,),) ] result = """\ ('f_enter_0_args',) {'in': 'in'} () {} refused args ('f_exit_0_args',) {} """ buf = StringIO() tryFinally(lst) assert buf.getvalue() == result From p.f.moore at gmail.com Tue Oct 11 21:13:33 2005 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 11 Oct 2005 20:13:33 +0100 Subject: [Web-SIG] a convenient way to deeply nest try/finally statements In-Reply-To: References: Message-ID: <79990c6b0510111213p77df92cbjb11355ed4b2cf87a@mail.gmail.com> On 10/11/05, Shannon -jj Behrens wrote: > I'm posting this in the hope someone else will find it useful. If you > want it, consider it in the public domain. Hmm, I like it. Thanks - saves me waiting for Python 2.5 and the "with" statement :-) (It was badly mangled by gmail, but still possible to understand the principle). Paul. From jjinux at gmail.com Fri Oct 14 02:05:54 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Thu, 13 Oct 2005 17:05:54 -0700 Subject: [Web-SIG] a convenient way to deeply nest try/finally statements In-Reply-To: <79990c6b0510111213p77df92cbjb11355ed4b2cf87a@mail.gmail.com> References: <79990c6b0510111213p77df92cbjb11355ed4b2cf87a@mail.gmail.com> Message-ID: On 10/11/05, Paul Moore wrote: > On 10/11/05, Shannon -jj Behrens wrote: > > I'm posting this in the hope someone else will find it useful. If you > > want it, consider it in the public domain. > > Hmm, I like it. Thanks - saves me waiting for Python 2.5 and the > "with" statement :-) (It was badly mangled by gmail, but still > possible to understand the principle). Reposted from the baypiggies mailing list so as not to cross post: I was following the "with" statement thing for a while, but eventually gave up on keeping up with the dev mailing list. Please correct me if I'm wrong, but the benefit of my library is also that you don't have to nest things inside each other. I.e. it's a flat list of (init, destruct) that is implemented as nested try/finallys but doesn't look like that. Hence, it's easy to construct such lists and rearrange them dynamically [or inject things into them from within subclasses]. Am I mistaken? -- Hacking is to climbing Mt. Everest as software engineering is to building a Denny's there. From p.f.moore at gmail.com Fri Oct 14 11:05:54 2005 From: p.f.moore at gmail.com (Paul Moore) Date: Fri, 14 Oct 2005 10:05:54 +0100 Subject: [Web-SIG] a convenient way to deeply nest try/finally statements In-Reply-To: References: <79990c6b0510111213p77df92cbjb11355ed4b2cf87a@mail.gmail.com> Message-ID: <79990c6b0510140205m39535204q114005c253f49cf2@mail.gmail.com> On 10/14/05, Shannon -jj Behrens wrote: > I was following the "with" statement thing for a while, but eventually > gave up on keeping up with the dev mailing list. Please correct me if > I'm wrong, but the benefit of my library is also that you don't have > to nest things inside each other. I.e. it's a flat list of (init, > destruct) that is implemented as nested try/finallys but doesn't look > like that. Hence, it's easy to construct such lists and rearrange > them dynamically [or inject things into them from within subclasses]. > > Am I mistaken? No, you're right, but I had assumed it would be easy enough to write a "combined" function which allowed you to transform with a: with b: with c: whatever into with combined(a,b,c): whatever Having said that, this is probably just what your library does, but recast to work with the "with" statement... Paul. From ksenia.marasanova at gmail.com Fri Oct 14 13:21:28 2005 From: ksenia.marasanova at gmail.com (Ksenia Marasanova) Date: Fri, 14 Oct 2005 13:21:28 +0200 Subject: [Web-SIG] Standard request / response objects? Message-ID: <130df1930510140421i73f838a6l@mail.gmail.com> Hi, I found some old thread on this subject, but not much further info... Anyone aware of some standard http request / response componenets, that can be used in multiprocess environment? It seems that every framework reinvents it again and again. It would be cool to have request / response in a separate project, like Routes ;-). -- Ksenia From ben at groovie.org Sat Oct 15 02:30:22 2005 From: ben at groovie.org (Ben Bangert) Date: Fri, 14 Oct 2005 17:30:22 -0700 Subject: [Web-SIG] Accessing deeply nested multiple doc roots for WSGI apps Message-ID: As I'm working on some tools to facilitate the easy use and distribution of WSGI apps and middleware, a problem is starting to crop up. Most of these WSGI apps come with their own little set of static files (images, javascript, etc.) that need to be delivered should they be executed. Of course, Apache and such only allow for a single doc-root so I can't exactly through in each WSGI app's path to the static files. These static paths are also very deep as the WSGI apps are installed as Python egg's. I've been using Ian's StaticURLParser from Python Paste, but its speed concerns me plus the fact that it means my webapp is essentially doing little more than relay filesystem data. Several thoughts occur to me to deal with this: 1) Have a faster version of StaticURLParser, perhaps written in C 2) Create some sort of specification for a single static docroot where each WSGI egg gets its own symlink into #1 still leaves me with the WSGI app sending static data, which isn't ideal but so far it works and I can put the WSGI app under any URL prefix without a problem. It also requires me to dynamically generate the URL to all static information. #2 is probably easier in some respects, since if the scheme is a given (ie, /media/PACKAGE/VERSION/FILE.GIF) then I don't need to generate all the URL's and the webserver can be pointed to the static files root. Has anyone else thought of ways to deal with this? If I missed some prior thread about this exact topic that solves it, sorry. - Ben From jason at pengale.com Sat Oct 15 08:21:50 2005 From: jason at pengale.com (Jason Stitt) Date: Sat, 15 Oct 2005 01:21:50 -0500 Subject: [Web-SIG] Accessing deeply nested multiple doc roots for WSGI apps In-Reply-To: References: Message-ID: On Oct 14, 2005, at 7:30 PM, Ben Bangert wrote: > 1) Have a faster version of StaticURLParser, perhaps written in C > 2) Create some sort of specification for a single static docroot > where each WSGI egg gets its own symlink into > > #1 still leaves me with the WSGI app sending static data, which isn't > ideal but so far it works and I can put the WSGI app under any URL > prefix without a problem. It also requires me to dynamically generate > the URL to all static information. I agree with you that sending static files over WSGI is not ideal, in general. Depending on the server implementation you are using it is theoretically possible to take advantage of sendfile() for performance: http://www.python.org/peps/pep-0333.html#optional-platform-specific- file-handling But if you are using FastCGI or SCGI (e.g. with Flup) instead of running within the HTTP server itself (e.g. with mod_python), I'm not sure if that will work. (Anybody more familiar with Flup's capabilities, or whether any currently available server implements that part of the PEP?) Can you set up Squid or a similar proxy and cache static URLs? That would probably get rid of any performance problems. > #2 is probably easier in some respects, since if the scheme is a > given (ie, /media/PACKAGE/VERSION/FILE.GIF) then I don't need to > generate all the URL's and the webserver can be pointed to the static > files root. Personally, I wouldn't base the URL/filename on the package name and version. What if you wanted to run multiple instances of the same application, each with its own files? Some of them could be dynamically generated, or maybe the header graphic just needs to be different for each instance. And if any of these files might be linked to externally, you don't want a changing version # in there. The publishing engine I'm planning (yeah, I know, everyone has one these days, don't they?) needs to be able to run as many different sites as I want on one server. Anything to do with filesystem paths and base URLs/hostnames will be configured per site, so I don't have a standard naming scheme in the code itself. This does mean "generating" URLs, but you're going to have to do that for links between pages anyway, right? Jason P.S. New on this list. Is there an introduction protocol, and is it more or less complicated than HTTP? ;-) From skfriese at gmail.com Mon Oct 17 16:57:46 2005 From: skfriese at gmail.com (Sean K. Friese) Date: Mon, 17 Oct 2005 10:57:46 -0400 Subject: [Web-SIG] IIS 6.0 Trouble With "os.getcwd()" Message-ID: <9243d7030510170757ub1accbdpcc7bb491ed33f4cb@mail.gmail.com> Greetings! Anyone encounter an issue when using "os.getcwd()" in a Python CGI script called from an IIS 6.0 box? Apparently the only thing that is ever returned is the root of the virtual directory the script is in. No matter how deep the script is nestled, you'll never end up with the actual current working directory of the script. This kills two of my apps that I'm migrating to version 6.0 so far. It appears to be broken, but then again, with my limited experience in IIS 6.0, there *could* be some setting in there that is causing this, but I doubt it. Is there a workaround, or alternatively, is there another way to get the current working directory of the script being requested? I've tried a few things, but can't find something that is as "portable", without hardcoding at least one string somewhere! Thanks in advance! -Sean K. Friese -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20051017/c376fe4e/attachment.html From aaryal at foresightint.com Mon Oct 17 17:05:40 2005 From: aaryal at foresightint.com (anoop aryal) Date: Mon, 17 Oct 2005 10:05:40 -0500 Subject: [Web-SIG] IIS 6.0 Trouble With "os.getcwd()" In-Reply-To: <9243d7030510170757ub1accbdpcc7bb491ed33f4cb@mail.gmail.com> References: <9243d7030510170757ub1accbdpcc7bb491ed33f4cb@mail.gmail.com> Message-ID: <200510171005.40883.aaryal@foresightint.com> On Monday 17 October 2005 09:57 am, Sean K. Friese wrote: > Greetings! > Anyone encounter an issue when using "os.getcwd()" in a Python CGI script > called from an IIS 6.0 box? > Apparently the only thing that is ever returned is the root of the virtual > directory the script is in. No matter how deep the script is nestled, > you'll never end up with the actual current working directory of the > script. This kills two of my apps that I'm migrating to version 6.0 so far. > It appears to be broken, but then again, with my limited experience in IIS > 6.0, there *could* be some setting in there that is causing this, but I > doubt it. Is there a workaround, or alternatively, is there another way to > get the current working directory of the script being requested? I've tried > a few things, but can't find something that is as "portable", without > hardcoding at least one string somewhere! try: os.path.abspath(os.path.join(os.getcwd(), os.path.dirname(sys.argv[0])) anoop. > Thanks in advance! > -Sean K. Friese From skfriese at gmail.com Mon Oct 17 18:13:45 2005 From: skfriese at gmail.com (Sean K. Friese) Date: Mon, 17 Oct 2005 12:13:45 -0400 Subject: [Web-SIG] IIS 6.0 Trouble With "os.getcwd()" In-Reply-To: <200510171005.40883.aaryal@foresightint.com> Message-ID: <4353cdb2.58aa2e31.540b.ffffe3e1@mx.gmail.com> Works great! Thanks! -----Original Message----- From: web-sig-bounces+skfriese=gmail.com at python.org [mailto:web-sig-bounces+skfriese=gmail.com at python.org] On Behalf Of anoop aryal Sent: Monday, October 17, 2005 11:06 AM To: web-sig at python.org Subject: Re: [Web-SIG] IIS 6.0 Trouble With "os.getcwd()" On Monday 17 October 2005 09:57 am, Sean K. Friese wrote: > Greetings! > Anyone encounter an issue when using "os.getcwd()" in a Python CGI script > called from an IIS 6.0 box? > Apparently the only thing that is ever returned is the root of the virtual > directory the script is in. No matter how deep the script is nestled, > you'll never end up with the actual current working directory of the > script. This kills two of my apps that I'm migrating to version 6.0 so far. > It appears to be broken, but then again, with my limited experience in IIS > 6.0, there *could* be some setting in there that is causing this, but I > doubt it. Is there a workaround, or alternatively, is there another way to > get the current working directory of the script being requested? I've tried > a few things, but can't find something that is as "portable", without > hardcoding at least one string somewhere! try: os.path.abspath(os.path.join(os.getcwd(), os.path.dirname(sys.argv[0])) anoop. > Thanks in advance! > -Sean K. Friese _______________________________________________ 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/skfriese%40gmail.com From ianb at colorstudy.com Sun Oct 23 03:02:08 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 22 Oct 2005 20:02:08 -0500 Subject: [Web-SIG] Accessing deeply nested multiple doc roots for WSGI apps In-Reply-To: References: Message-ID: <435AE110.1040409@colorstudy.com> Ben Bangert wrote: > As I'm working on some tools to facilitate the easy use and > distribution of WSGI apps and middleware, a problem is starting to > crop up. Most of these WSGI apps come with their own little set of > static files (images, javascript, etc.) that need to be delivered > should they be executed. Of course, Apache and such only allow for a > single doc-root so I can't exactly through in each WSGI app's path to > the static files. > > These static paths are also very deep as the WSGI apps are installed > as Python egg's. I've been using Ian's StaticURLParser from Python > Paste, but its speed concerns me plus the fact that it means my > webapp is essentially doing little more than relay filesystem data. > > Several thoughts occur to me to deal with this: > > 1) Have a faster version of StaticURLParser, perhaps written in C > 2) Create some sort of specification for a single static docroot > where each WSGI egg gets its own symlink into I've thought about this too. I think a little of both is best -- have some configurable location where files can be dumped (using Package/Version/) and a URL that goes with that. Then I figure the application, on first startup, will either copy or symlink files into that location -- though sometimes the user the application runs as couldn't do that, so maybe there should be a way to make it happen separately from running the application. In fact, maybe it could simply be some seperate piece of metadata, so the application doesn't have to do it at all. Then the app should generate all the URLs based on that configured static location, or if no location has been configured it should fall back on StaticURLParser. The fallback is useful, especially in a situation like a standalone HTTP server where there isn't any static serving (or at least none that is particularly better than StaticURLParser). -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From remi at cherrypy.org Sun Oct 23 17:40:39 2005 From: remi at cherrypy.org (Remi Delon) Date: Sun, 23 Oct 2005 16:40:39 +0100 Subject: [Web-SIG] ANN: CherryPy-2.1.0-final released Message-ID: <007801c5d7e8$1f6319a0$f5969751@acer684c9a655d> Hello everyone, I am happy to announce the release of CherryPy-2.1.0 It is the result of 6 months of intense development since the last stable release and the work of a growing number of contributors. CherryPy has become increasingly popular these past few months (the mailing lists now have more than 500 people) and it is also used in other popular products such as Subway and Turbogears. This release is a major step forward for CherryPy. It is packed with new features and bug fixes. Here are the main improvements in this release: - New WSGI interface, which allow CherryPy sites to be deployed on any WSGI server. People are already running it on mod_python, FastCGI, SCGI, IIS or CherryPy's own built-in HTTP server. - New implementation for sessions, which supports multiple backends - Built-in list of convenient "filters" for things like gzip compression, XHTML validation, caching, unicode decoding/encoding, authentication, XML-RPC wrapper, etc ... These filters can easily be enabled/disabled through configuration. - New "development" mode which provides things like autoreload (no need to manually restart your server when you make a change), logging of page stats, etc ... - Better handling of file uploads - Internal implementation now uses generators everywhere (no more StringIO) - New built-in HTTP server implementation *************** About CherryPy: CherryPy-2 is a pythonic, object-oriented web development framework. Here is a sample Hello, World in CherryPy-2: # import cherrypy # class HelloWorld: # @cherrypy.expose # def index(self): # yield "" # yield "Hello world!" # yield "" # cherrypy.root = HelloWorld() # cherrypy.server.start() Main properties: - this code starts a multi-threaded HTTP server that dispatches requests to methods - requests like "http://domain/dir/page?arg1=va l1&arg2=val2" are mapped to "dir.page(arg1='val1', arg2='val2')" - CherryPy also supports "RESTful" URLs like http://domain/book/science/9 - requests are mapped to an object tree that is "mounted" on cherrypy.root (for instance: "cherrypy.root.user", "cherrypy.root.user.remi", ...) - method must be explicitly exposed with a decorator "@cherrypy.expose" (or "index.exposed = True" for Python-2.3) Remi. http://www.cherrypy.org From lists at theorganization.net Sun Oct 23 19:52:34 2005 From: lists at theorganization.net (Jos Yule) Date: Sun, 23 Oct 2005 13:52:34 -0400 Subject: [Web-SIG] ANN: CherryPy-2.1.0-final released In-Reply-To: <007801c5d7e8$1f6319a0$f5969751@acer684c9a655d> References: <007801c5d7e8$1f6319a0$f5969751@acer684c9a655d> Message-ID: <435BCDE2.4080101@theorganization.net> Congratulations to the whole cherrypy team and community! j -- jos yule Digital Hyakugei mailto:jos at theorganization.net From mo.babaei at gmail.com Mon Oct 24 10:06:21 2005 From: mo.babaei at gmail.com (mohammad babaei) Date: Mon, 24 Oct 2005 11:36:21 +0330 Subject: [Web-SIG] Best Python IDE with FTP Message-ID: <5bf3a41f0510240106m75f5a86ve4b13f42855ae141@mail.gmail.com> Hi, I'm looking for a python IDE with FTP/SFTP feature to work with remote servers Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20051024/3aeb35db/attachment.html From sa at c-area.ch Mon Oct 24 19:13:26 2005 From: sa at c-area.ch (Steven Armstrong) Date: Mon, 24 Oct 2005 19:13:26 +0200 Subject: [Web-SIG] Best Python IDE with FTP In-Reply-To: <5bf3a41f0510240106m75f5a86ve4b13f42855ae141@mail.gmail.com> References: <5bf3a41f0510240106m75f5a86ve4b13f42855ae141@mail.gmail.com> Message-ID: <435D1636.3080107@c-area.ch> On 10/24/05 10:06, mohammad babaei wrote: > Hi, > I'm looking for a python IDE with FTP/SFTP feature to work with remote > servers > Regards > Hi Mohammad I use eclipse [1] with pydev [2]. Eclipse comes with CVS and SVN built in and offers FTP/WebDAV through plugins. There is also a sftp plugin [3], but I can't tell you anything about that. hth Steven [1] http://www.eclipse.org/ [2] http://pydev.sf.net/ [3] http://klomp.org/eclipse/org.klomp.eclipse.team.sftp/ From titus at caltech.edu Tue Oct 25 04:31:56 2005 From: titus at caltech.edu (Titus Brown) Date: Mon, 24 Oct 2005 19:31:56 -0700 Subject: [Web-SIG] RELEASE: session2 v0.6 Message-ID: <20051025023156.GA30545@caltech.edu> Hello all, I've just released version 0.6 of session2, our (Mike Orr's and mine) rewrite of session management for Quixote 2.x. Visit the Web site at http://quixote.idyll.org/session2/ session2 offers a (in our opinion) vastly improved session management API that more cleanly *supports* SQL-based persistence, as well as multiprocess & threadsafe execution models. It actually implements multiprocess-safe session stores for MySQL, PostgreSQL, and Durus, and session2 provides file/directory and shelve-based stores as well. The two main updates for v0.6 are both documentation updates: * expanded README (index page at the Web site) and * epydoc-based source code documentation. session2 is also available via the Python Package Index at http://www.python.org/pypi/session2/0.6 and on the quixote_extras site at http://cafepy.com/quixote_extras/titus/session2/ enjoy, --titus