Re: Is FormEncode maintained?
Hi Juliusz. I'm actually in the process of passing maintainership onto a new person. But in the meantime I'd be happy to give you push rights to the repo; especially i18n issues tend to be poorly handled by Americans, because we don't even notice when we break things :( -- send me your bitbucket username, and then we should be able to get a new release out after that. 2011/3/30 Juliusz Gonera jgon...@gmail.com Hi, I would like to know if FormEncode is still maintained by someone. I found a bug that disables all non-English translations of messages in FormEncode 1.2.3dev ( http://sourceforge.net/tracker/?func=detailatid=596416aid=3153489group_id=91231). I would like someone to rerelease it with this bug fixed. If there are no maintainers I would like to get the necessary rights to fix this bug myself and release a new version. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
WebOb 1.0
WebOb 1.0! This doesn't represent any particular development event, simply an acknowledgement that WebOb is well past what would be called 1.0 -- stable, complete, with a well-defined scope, and as a dependency for many other projects its API is and should be very stable. Thanks to everyone who helped, and in particular to Sergey Schetinin for his ongoing help with many a bug fix. -- Ian Bicking | http://blog.ianbicking.org -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Paste 1.7.4, security fix for XSS hole
Paste 1.7.4 is released. The only real change is to paste.httpexceptions, which was using insecure quoting of some parameters and allowed an XSS hole, most specifically with its 404 messages. The most notably WSGI application using this is paste.urlparse.StaticURLParser and PkgResourcesParser. By directing someone to an appropriately formed URL an attacker can execute arbitrary Javascript on the victim's client. paste.urlmap.URLMap is also affected, but only if you have no application attached to /. Other applications using paste.httpexceptions may be effected (especially HTTPNotFound). WebOb/webob.exc.HTTPNotFound is not affected. I believe the changes to 1.7.4 are limited and upgrading will have a low impact. This security hole was found by Tim Wintle http://www.rubberrepublic.com/ and I think entirely separately just a couple days later by Georg-Christian Pranschke http://sensepost.com. I'm sorry about this, I hope this won't cause you too much trouble. -- Ian Bicking | http://blog.ianbicking.org -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Disadvantage/Drawback - Deployment Paster directly on port 80 without be a root
On Wed, Jun 23, 2010 at 3:47 PM, Mario Moura moura.ma...@gmail.com wrote: Wich disadvantage? Of course I know that port 80 in Paster can only open with root. Why? Serious Why? Eh, kind of lame reasons related to multi-user systems. Try using authbind, it will allow you to bind to port 80 without starting paster as root. -- Ian Bicking | http://blog.ianbicking.org -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: WebOb API
On Wed, Nov 18, 2009 at 12:11 PM, Jonathan Vanasco jonat...@findmeon.comwrote: On Nov 16, 2:50 pm, Ben Bangert b...@groovie.org wrote: - Fixed bug in Python stdlib regarding handling of 'bad' cookies. Ie, if Python is parsing 4 cookies, and the first one is 'invalid', Python *stops parsing* the rest! This is bad as several webapp systems use the character Python doesn't like, so having it on the same domain as a Python app (not werkzeug) means cookies just disappear since Python stops parsing them. the 'bad cookie' thing would be great to see happen sooner-than- later. a few years ago, wordpress created malformed cookies ( they didn't conform to the RFC and either used restricted chars , or didn't quote or something, i can't remember ). a project that i had ran wordpress for the blog/news , and mod-perl for an application. the second libapreq ( the cooking parsing apache module ) encountered a malformed cookie... segfault. its a rare thing to have, but incredibly frustrating to deal with if it ever happens. If someone wants to work on this, WebOb is in bitbucket now, so you can clone and patch and do a pull request: http://bitbucket.org/ianb/webob -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=.
Re: WebOb API
On Mon, Nov 16, 2009 at 1:50 PM, Ben Bangert b...@groovie.org wrote: The fixes I was aware of that Armin has worked around in Werkzeug: - Multipart parsing that doesn't suck, better file upload handling - Fixed bug in Python stdlib regarding handling of 'bad' cookies. Ie, if Python is parsing 4 cookies, and the first one is 'invalid', Python *stops parsing* the rest! This is bad as several webapp systems use the character Python doesn't like, so having it on the same domain as a Python app (not werkzeug) means cookies just disappear since Python stops parsing them. I would like to include these fixes or improvements over the standard library, but they don't affect the API so it's not a 1.0 blocker. I think there was one or two other things related to having a cgi.fieldstorage that doesn't suck, and some other header parsing that Werkzeug might handle better. But these are what I'd consider critical fixes for getting into WebOb. Does Werkzeug use cgi.FieldStorage, given that it has its own parser? Getting FieldStorage objects out of req.POST (and into req.FILES with a different API) would be important, and make the transition to another parser primarily an implementation detail. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Fri, Nov 13, 2009 at 2:46 PM, Philip Jenvey pjen...@underboss.orgwrote: On Nov 1, 2009, at 5:39 PM, Ian Bicking wrote: On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert b...@groovie.org wrote: On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). Another thing Armin specifically mentioned is that he doesn't like that all WebOb requests are mutable. He prefers the Werkzeug setup where the base request object is basically read-only, and there is a subclass that can be written to. First, that would be rather hard to do with WebOb (maybe a read-only flag would be possible, but the functionality would be there regardless, only explicitly disabled via a flag), and secondly I don't particular agree with him on this matter, and I don't think there's a strong justification for removing this functionality (I am of a mind that if you don't want to modify the request, then don't do it). There's at least some good arguments for immutability: o Request object becomes much simpler with way less code (see Werkzeug) The code needs to exist somewhere, so eh. And if the two were separated, the result would be more total code. o Becomes easier to cache attributes and avoid property overhead (see Werkzeug) That's not so much of an issue of immutability, as the authoritative nature of the request object or the environ. WebOb treats the environ as authoritative. It could be mutable and safely cache attributes, so long as the expectation is that no one else can change the environ using anything but the request object API. o You can still change environ you just have to do it manually o One step towards Werkzeug possibly adopting WebOb (when the aforementioned goal was being adopted by more frameworks) The drawbacks are we lose that sometimes handy functionality and that WebTest relies on it. How much does WebTest really rely on it though (it doesn't really seem like much)? WebTest primarily uses WebOb, and then adds some stuff for forms, and some APIs that are more backward compatible than essential. The mutability functionality is also useful to middleware. And just to clarify, the Werkzeug wrappers aren't totally immutable, you can still modify their attributes and add your own attributes. Its exposed data structures (like MultiDicts) are immutable and it doesn't write to environ. A middle ground might be what Werkzeug does now but allowing writes to data structures like MultiDicts -- just not propagating the changes to environ. Why not propagate changes? My philosophy with WebOb is if it does something, it should do it right. Not propagating changes is just wrong (AttributeError is more right in that case). If there are other things I'm not aware of them; you'll have to list them more specifically. Werkzeug also has some pieces of functionality separated out via Mixins, this mainly makes the code cleaner. It doesn't actually have a mutability Mixin, that's just a proposal by Armin to find a middle ground with WebOb. If the code exists, and can have a canonical form, I don't really see a reason not to include it. There is some code that is not possible to write in a canonical form. The two biggies are User-Agent parsing (which is eclectic and changes over time) and authentication methods. One big difference is it stores file uploads in a different container than the main request.POST multidict, and more importantly doesn't use cgi.FieldStorage for those file objects or for parsing the form. With that alternative form parser you can also easily limit the size of form posts/file uploads. Yes, this is something I'm interested in including in WebOb. The other API differences are probably mostly
Re: WebOb API
On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert b...@groovie.org wrote: On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). Another thing Armin specifically mentioned is that he doesn't like that all WebOb requests are mutable. He prefers the Werkzeug setup where the base request object is basically read-only, and there is a subclass that can be written to. First, that would be rather hard to do with WebOb (maybe a read-only flag would be possible, but the functionality would be there regardless, only explicitly disabled via a flag), and secondly I don't particular agree with him on this matter, and I don't think there's a strong justification for removing this functionality (I am of a mind that if you don't want to modify the request, then don't do it). If there are other things I'm not aware of them; you'll have to list them more specifically. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebOb API
On Fri, Oct 30, 2009 at 12:32 PM, Jonathan Vanasco jonat...@findmeon.com wrote: Are there API changes that would help people consider WebOb for other frameworks? Personally, I don't like the default behavior of how request.params.get/post handles the multidict -- in that it returns ONE by default. that drove me crazy trying to figure out how posted arrays were supported, and I nearly dropped using pylons because the getall behavior was completely hidden in the documentation at that point. i'd honestly like to see get() listed for deprecation, and just have getone and getall. It's based on the dictionary API. get basically means: def get(self, key, default=None): if key in self: return self[key] else: return default So it makes sense based on that. In some other frameworks I worked with places where you would get a single value or a list depending on how many values were passed in, and I found it generally less productive, so multidict acts like a flat single-value dictionary unless you use something specific (like getall). There's no standard API I really know of for a dict-view over a list. There's an ordered dict in Python now, but it's single-value, so it has no real API over a normal dictionary. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
WebOb API
Hi all. So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. While I haven't tracked ongoing changes to frameworks, I did put together the differences I am aware of in APIs here: http://pythonpaste.org/webob/differences.html Some of them are fairly trivial, and could be managed through subclassing (e.g., req.raw_post_data vs. req.body -- semantically identical, just different names). Are there API changes that would help people consider WebOb for other frameworks? The main ones I can think of is req.FILES, separating out file uploads from other POST fields. Also then there's the issue of what kind of object represents files. The finer details of individual objects are also important, things like the API of req.GET/req.POST (which are views on ordered dictionaries, and are represented somewhat differently in different frameworks). Also I'm planning on introducing a BaseRequest (and *maybe* BaseResponse) class, that removes some functionality. Specifically for Repoze they'd like to remove __getattr__ and __setattr__ (which has some performance implications), and maybe other things are possible (though removing writers is infeasible, IMHO, as read and write access are not easily separated, and it would require too much code duplication). (Incidentally WebOb is now on bitbucket: http://bitbucket.org/ianb/webob/) -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: parsing ini files?
For whatever reason I didn't use it in Paste Deploy, but INITools is a
separate config parser from ConfigParser, but compatible, and you can
enable some typical options fairly easily (things like ${} parsing,
similar to how buildout config files work):
http://pythonpaste.org/initools/
On Mon, Oct 26, 2009 at 3:48 PM, Iain Duncan iaindun...@telus.net wrote:
Hi folks, wondering if anyone can tell what Pylons (Paste?) uses for
parsing the ini files. I'm breaking some of my app into it's own package
and want to have it parse a local ini file if that component gets used
on it's own separately from the pylons app, but I'd like to use whatever
is the standard in Pylons to do so.
Thanks
Iain
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Pylons on Google App Engine article
On Fri, Oct 16, 2009 at 5:57 PM, Matt Feifarek matt.feifa...@gmail.com wrote:
I don't use paster serve, and wouldn't recommend it. You can/should
use paste.deploy.loadapp('development.ini') in your main.py or
runner.py or whatever script, and then use dev_appserver.
Would you mind expanding on that a little bit? Why don't you recommend it?
On GAE specifically, dev_appserver does all the fixups and security
restrictions to make it a mostly representative environment. So you
should just use dev_appserver.
Generally, I'll note one advantage to GAE that you should make use of:
once a set of libraries is working, everything to make them work is in
a set of portable files (.py files and directories and whatnot).
After installing I check *all* the files into version control.
Cool. Good concept. But it seems like once you do something like that (or
like moving your libraries into the GAE app) you can't manage the
virtualenv install anymore (like adding new distributions with pip). I
suppose one can always manually add them.
pip install works with appengine-homedir. A couple things are
installed outside of the app/ directory, but once it's setup there's a
file in lib/python2.5/distutils/distutils.cfg that makes everything
install into app/lib/python.
When I update a library or install something new, I just run another
commit after.
appengine-homedir
is one attempt to get installation working reasonably. The intent of
appengine-homedir is also that you check app/ into version control
(but not the enclosing virtualenv environment). It would be kind of
nice if app/ had some script included to recreate the enclosing
virtualenv environment.
It *seemed* to me that once appengine-homedir got running, the VE is
basically moot; you no longer run the devappserver from it, right? Since
your runner.py script does all of the sys.path manipulations, there's no
point in keeping the VE bin and lib and what-not around, especially if you
don't recommend using paster serve.
I recommend the venv for running python interactively, running tests,
and installing things.
that way). Also I mostly got rid of configuration, as GAE apps aren't
generally configured (due to the static nature of the deployment).
But that broke paster controller and paster shell (though with what
sitecustomize does paster shell isn't as necessary). Restoring
development.ini, or allowing it as an option, would be easy enough to
Why isn't paster shell necessary? Seems like sitecustomize.py is mostly
about fixing imports and shim'ing things into sys.path.
It also sets up the data store, so you can access and use your models.
It doesn't set up the entire configuration of your app, but the most
important configuration is generally persistence, which sitecustomize
handles. And maybe it could even handle more if it was useful to do
so.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Pylons on Google App Engine article
reasonably. The intent of appengine-homedir is also that you check app/ into version control (but not the enclosing virtualenv environment). It would be kind of nice if app/ had some script included to recreate the enclosing virtualenv environment. Another detail I guess is what your app is named -- each person might name it differently, and that effects the file locations, so makes a simple tar/zip file harder. Are app names worth it? I don't know... could you name them all app and be done with it? If you start combining multiple apps it might matter, but people haven't done that much (though it is possible, and several GAE tools are distributed that way). Also I mostly got rid of configuration, as GAE apps aren't generally configured (due to the static nature of the deployment). But that broke paster controller and paster shell (though with what sitecustomize does paster shell isn't as necessary). Restoring development.ini, or allowing it as an option, would be easy enough to do. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons on GAE long wake up time on first request
On Thu, Oct 15, 2009 at 3:53 PM, Matt Feifarek matt.feifa...@gmail.com wrote: It takes a long time (from 5 to 10 sec) to serve the first request if the instance is not hot. Is some body else experiencing this the problem? Yeah, I noticed that too. I can't explain it, but if you Google for it, you'll see others complaining. My guess is that the AppEngine infrastructure clears your app out of The Memory of The Google when it hasn't been used. Once it's used, it comes up instantly (the second time). I've noticed this also if I come back in a few hours (nobody else has hit my testing app, so I bet it gets garbage collected). Not sure what we can do about it. Perhaps if it's running some long-running tasks? I have to admit, as much as the high-availability of GAE is attractive, if hits are going to take 10s to come back, that's a pretty big negative. The only way to really fix this is to make the startup time of the app faster. I'm a little surprised with 10s, though if it was down to 3-5 seconds I probably would decide to not care, since the warmup is going to be a small percentage of requests (especially the requests people care about). Other warmup costs can be substantial too, like getting all the Javascript and CSS cached on the user's browser. Imports are probably slower on GAE because it doesn't use .pyc files. (Though why not, I'm not sure -- it should be able to generate its own .pyc files that it can trust on app upload.) Depending on your code layout, searching for packages might be slow (.egg directories will slow it down). I'm not sure if .egg directories will be significant, but they could be. Lazy importing will help, especially if some modules won't need to be loaded for the life of the process. Lazy loading alone might actually just spread the latency over multiple requests, perhaps leading to a worse speed perception than a single initial hit. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons on Google App Engine article
On Wed, Oct 14, 2009 at 4:35 PM, Matt Feifarek matt.feifa...@gmail.com wrote: This seems much better than my own recent work... I think it's a mistake to start with appengine-homedir... better to just start from stock Pylons and hack it till it works on GAE. That's been my discovery over the last few days, but I haven't patched my Pylons Wiki article yet. I personally got too annoyed with testing and general interactivity (there's a nose extension though, which I cribbed from -- but I never actually got it to work myself). -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Testing controllers on Google AppEngine: can it be done?
Testing should work fine -- the key is if you use appengine-homedir,
it'll setup your data store in sitecustomize.py (automatically on
Python startup), then you get your application instance by calling
make_app directly. So it should look like:
testapp = webtest.TestApp(myapp.wsgiapp.make_app({}, {config}))
# do stuff with testapp
Or replace whatever code currently uses paste.deploy.loadapp with this
direct make_app call.
On Sat, Oct 10, 2009 at 12:25 AM, Matt Feifarek matt.feifa...@gmail.com wrote:
I've been working on getting Pylons running on GAE and documenting my
discoveries.
(see thread here:
http://groups.google.com/group/pylons-discuss/browse_thread/thread/fa7d8defef1babfa/a16416074cca2660?lnk=raot#)
I seem to have stumped myself as far as running tests with WebTest et al.
Since test.ini is gone, and since the app is no longer run via paste (but by
the GAE SDK) is it reasonable to run nosetests on controllers?
Thanks.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Pylons on Google App Engine
On Thu, Oct 8, 2009 at 3:03 AM, Mike Orr sluggos...@gmail.com wrote: Also, I probably have some terminology wrong: I'm not sure what the meta files like MANIFEST.in and ez_setup.py actually are... are they egg files? Paster files? Setuptools? I don't know what to properly call them when I talk about deleting them. The egg-info directory contains package metadata. These are necessary because Paste uses various runtime services provided by Setuptools, which depend on the metadata for package introspection and entry points. Also if you want to update packages, or install a new package and make use of your existing installed dependencies, you'll want those egg-info directories that describe the packages. If you don't use setuptools at runtime (which you don't have to) then you can skip uploading them to the server via skip_files in app.yaml. ez_setup.py is unnecessary, and I think MANIFEST.in is too. ez_setup.py is a script that downloads and installs Setuptools. It's customary to include it in packages whose setup.py depend on Setuptoos, as Pylons applications do. MANIFEST.in is used by setup.py to build the egg-info metadata. Neither of these are needed on the server, which never installs anything. Correct; I have in the past basically flattened things for appengine. Unfortunately that doesn't work well with paster create -t pylons. It might however be more productive to have an appengine template, since you already know what the models will have to look like, you can skip setup.py etc., and generally make a tighter setup. Some questions that I still have and can't answer: 1. Can one delete the *.egg-info directories in the app/lib portion of a GAE tree, or does that metadata get used in the standard operating of python (one of the reasons I HATE all of this packaging stuff; we have webob just where it's supposed to be, then the cruft WebOb-0.9.6.1-py2.5.egg-info (which is NOT a package) right next to it. But I digress... The metadata has to go somewhere, and there are two standard locations for it in Python. easy_install does it one way, and pip does it the other way. Pip's way has just one directory on sys.path, like in the olden days. Easy_install's way puts every friggin' package directory on sys.path using *.pth files.Besides being ugly, this is one more point of failure if the path doesn't get set right. As has happened to me before on App Engine, when it ignored *.pth files sometimes. I wish Paste did not depend on Setuptools and entry points, but it does, and we're not going to get away from that until we write another framework. (Which the Pype framework might be someday.) Paste doesn't really depend on Setuptools. Paste Deploy does, with its configuration files. But you don't have to use them. The way I believe I have it setup with appengine-homedir is that it invokes the make_app function directly. So at runtime (i.e., in the appengine environment) you don't need Setuptools or egg-info files (or ini files). The justification being that you don't really configure appengine apps, as they are all essentially one-off. This isn't entirely true, but... eh. You need a new app.yaml for each instance, so appengine defies the simplest configuration anyway. 2. There are still files in an appengine-homedir from monkey: ./app/lib/python/appengine_monkey_files. I don't know what they're for (if anything). I removed them in my experimentation, seems ok so far. Those are probably things I missed when I was deleting the monkey code. 3. Much of anything about zipped / unzipped packages. Google raised the quotas significantly after we bitched long enough about it. I think it's 3000 files now, which is enough for a good-sized Pylons application wiithout zipping. Before it was 1000 files, which just barely fit Pylons. The issue of course is that no other runtime environment imposes a file quantity restriction, so the packages were not designed to economize files. And more than half of Pylons and Routes is backward compatibility code, which is needed now but will be gone by Pylons 1.0. You should be able to use the command pip zip package to zip a package (not a Distribution, but a package -- i.e., the thing you import). So if you need to zip, you can. pip zip can also count files, to help suggest what you might zip. appengine-monkey also came with a script to analyze skip_files and help you decide how to skip files, or why a file is skipped. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group
Re: Using Django Forms with Pylons (and a successor to @validate?)
On Sun, Oct 4, 2009 at 2:36 PM, Mike Orr sluggos...@gmail.com wrote: On Sun, Oct 4, 2009 at 12:02 PM, Kevin J. Smith ke...@rootsmith.ca wrote: I am not so sure why everyone seems to be so unhappy with FormEncode. I find it a rather brilliant solution. There is definitely a steeper than average learning curve but like all things that are powerful and can be adapted to any situation, there is always a tradeoff. I would hate to see support for FormEncode lost in Pylons. I currently use @validate with custom validators and formatters with htmlfill with great success. I think it would be a great loss to move to some simpler solution that is not as powerful. The reason I chose Pylons is for its power to adapt, otherwise, I would have gone with Django - less learning curve but less adaptable. If there is going to be support added for an alternative form processing framework on top of FormEncode then that is great but I would hate to see FormEncode dropped. I know that I could always continue using FormEncode because Pylons is flexible but maintaining @validate on my own is not the ultimate situation. It's too late to drop FormEncode, htmlfill, and the form helpers. We've been promising people for months that the biggest changes in Pylons have already been done. It's one thing to drop a bad set of helpers (the rails helpers, buggy and unmaintainable). It's another thing to completely change the form+validation API.FormEncode works; it's just under-documented and the code contains dead-end cruft (i.e., useless validators). I'm just thinking that if Pylons were being created now, WTForms might have been a better approach, and Ian might not have written FormEncode in the first place. If things were different, then different things would be done. Looking at WTForms, it looks like it is both widgets and validation, and it could use FormEncode validation largely in the same way it uses its current validation. It's always been possible to embed FormEncode in other systems, and keeping FormEncode focused strictly on validation allows for that. I can't make anyone pay attention to FormEncode, its scope, or what it does... but I can hardly get excited about development that ignores it. I'm glad Marcus is trying out different ways of handling control flow. The library I wrote before FormEncode included control flow and framework bindings, and it kind of sucked -- I left them out of FormEncode so people could wrap it however they thought best. @validate is one such wrapping, but more explicit control flow is usually much easier to understand, which is what Marcus seems to have implemented. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: File manager
It's old and kind of broken, but I wrote a file browser example-ish thing a long time ago: http://svn.pythonpaste.org/Paste/apps/FileBrowser/ Oh dumb, apparently I started but didn't finish porting it to Pylons, and I didn't tag the old version (that wasn't just full of stubs). If you looked in the log you'd find it. It probably used Wareweb or something. For auth you might be able to use repoze.what, or I think there's a TG middleware for path-based authorization. On Mon, Sep 28, 2009 at 12:31 AM, Mike Orr sluggos...@gmail.com wrote: What are people's recommendations for a simple Python-based file manager? Our users are getting tired of the FTP interface and active/passive dilemma on our FTP server, and many people we exchange files with don't have FTP clients installed, so I'm looking for a web interface that can either sit on top of the FTP directory or be installed on another server. (Windows in the former case; Linux in the latter.) Plone would be overkill, and while I could write one in Pylons, I expect somebody already has, and has made a better directory-tree interface than I can. Bonus if it's written in Pylons or can be embedded as a WSGI application, but these are not strictly necessary. Authorization is currently just a couple levels, although we may want something more complex later. -- Mike Orr sluggos...@gmail.com -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: cron Paster Command
There's also a paster request command that is GREAT for cron jobs. GREAT! On Fri, Sep 18, 2009 at 3:52 PM, Raoul Snyman raoul.sny...@gmail.comwrote: Hi guys, I've recently been investigating how to run cron jobs for my Pylons applications, and followed the example I found on the wiki by creating a paster command. I've blogged about it, and uploaded the script to my blog. http://is.gd/3qpl6 One of the cool things about it (if I may brag a little!) is that you don't have to do much to get it up and running. The command class will find all your controllers, and will run a cron command if it exists in your controller. Constructive criticism is welcome! -- Raoul Snyman B.Tech Information Technology (Software Engineering) E-Mail: raoul.sny...@gmail.com Web: http://www.saturnlaboratories.co.za/ Blog: http://blog.saturnlaboratories.co.za/ Mobile: 082 550 3754 Registered Linux User #333298 (http://counter.li.org) -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Imports and memory usage
2009/7/20 Pavel Skvazh pavel.skv...@gmail.com I was going to ask this for ages now. For example we've got a controller. import os class MyController(BaseController): def do_stuff(): import os os.open(...) def do_more(): import os os.do(...) The question being, what's the best practice here for this exactly in pylons. When the server is launched, the top level import is done, making it availible for everyone in the module. If I'll only import os in the method, won't it cause more work to import it every single time the method is run? They are both basically equivalent. When you do an import os, the first thing it checks is sys.modules['os'], and if it's there it just returns that module object. This is pretty cheap, and no objects are created. You might even gain the time back because now os is a local variable, and those are slightly faster than globals (if you did import at the global scope). The only time memory is effected is if you wouldn't have imported os at all. For a more obscure module this might work, though generally it just means your application warms up -- everything gets imported eventually, but just not all at once, trading off startup time for a little delay when you do first load the module. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: There is no source code to display... Why?
I think this might be something wrong with the Javascript or CSS. There
should be a tab that displays that message, but you shouldn't see the tab --
instead when you view source it'll load the source code asynchronously and
show the tab. If JS or CSS didn't load, it might all display in a funky
way.
You could look at the source and check those JS and CSS links to make sure
they are working, or maybe they give a useful error message.
On Fri, Jul 10, 2009 at 6:12 AM, durumdara durumd...@gmail.com wrote:
Hi!
I used Pylons under apache (with proxy).
Interesting, when I use mod_rewrite with proxy (A), the Error page is
normal.
When I not use mod_rewrite, only proxypass (B), the Error page is
minimal and hardly readable.
In this case Pylons said: There is no source code to display...
What happened? What is the different?
A.) Good, but I have not change to set retry param of proxy.
ProxyPreserveHost On
TimeOut 600
ProxyTimeout 600
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/img/.*
RewriteCond %{REQUEST_URI} !^/error/.*
RewriteCond %{REQUEST_URI} !^/media/.*
RewriteCond %{REQUEST_URI} !^/css/.*
RewriteRule ^/(.*) http://127.0.0.1:10020/$1 [L,P]
B.) With retry - but error page changed to very simple view
ProxyPreserveHost On
TimeOut 600
ProxyTimeout 600
ProxyPassMatch /(img|error|media|css)/ !
ProxyPass / http://127.0.0.1:10020/ retry=120 timeout=600
ProxyPassReverse / http://127.0.0.1:10020/
So, what is the different?
Thanks for your help:
dd
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: There is no source code to display... Why?
On Fri, Jul 10, 2009 at 6:12 AM, durumdara durumd...@gmail.com wrote: ProxyPassMatch /(img|error|media|css)/ ! ProxyPass / http://127.0.0.1:10020/ retry=120 timeout=600 ProxyPassReverse / http://127.0.0.1:10020/ Oh yeah, that first line is probably what causes the problem. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pypes ...
On Mon, Jul 13, 2009 at 8:51 PM, Chris McDonough chr...@plope.com wrote: # cd pypes/pypes $ virtualenv --no-site-packages env $ env/bin/python setup.py develop To run the bfgish app: $ env/bin/python run.py I think you need repoze.profile to run this. OK... looking at pypes/bfgish/sampleapp/configure.yml... I am at first rather put off by all the --- !. I don't know what it means, and a quick read of the YAML spec isn't very helpful. i assume the empty sections could actually be left out, but they are kept in for documentation purposes. The whole BFG sample app is confusing to me. Looking at quickwiki I understand it a bit better, familiarity with the framework I suppose (but then it also does something, which is always helpful ;). The use of !include bothers me, though I can't articulate exactly why. Maybe because I've had bad experiences, e.g., gigantic Apache configuration boilerplate files that get included. I think it's how the configuration develops over time that bothers me. If there was room for persistent documentation that could be held in the configuration, and the ability to view the configuration with all includes resolved, that would make me more comfortable. I think debugging configuration troubles me, and this configuration definitely is something that can have hard bugs. Well, that's as far as I got for now. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: empty POST dictionary for post request when using webob.Request in middleware
Oh, it just occurred to me what's happening. WebOb is not replacing the body with an equivalent body; it tries to put back a lazily-recreated body that matches the original body when it parses the POST request, but it only works for application/x-www-urlencoded, not multipart/form-data. A not very great fix is just accessing req.body, and it should save the body verbatim when that attribute is accessed. Otherwise WebOb needs to recreate the body more correctly. What's odd is that usually this isn't a problem because WebOb puts the parsed fields in a special key in environ, and then just uses that instead of reparsing the body. I'm not sure why that isn't happening, or even why the request body is being parsed in this particular case. On Mon, May 18, 2009 at 1:38 AM, John Smallberries welch.quietple...@gmail.com wrote: Ummm, again, this works just fine if I remove that no-op middleware from the stack. The controller would then receive a populated POST dictionary that includes a FieldStorage element from which it can read the file contents. With the middleware in place, it's blank. Is there something more the middleware should be doing? Is it my form that is the problem? Here's some minimal html for a file upload form that fails in the same way as the above: html body form action=/test enctype=multipart/form-data method=post input name=upload size=50 id=upload type=file input value=Submit type=submit /form /body /html On May 15, 2:22 pm, Ian Bicking i...@colorstudy.com wrote: Your request looks weird: On Fri, May 15, 2009 at 2:57 PM, John Smallberries welch.quietple...@gmail.com wrote: Logfile output from the above: 2009-05-15 12:45:31 INFO handling request POST /testform Accept: text/xml,application/xml,application/xhtml+xml,text/ html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip, deflate Accept-Language: en-us Cache-Control: max-age=0 Connection: keep-alive Content-Length: -1 Content-Type: multipart/form-data; boundary= WebKitFormBoundaryGA7kzcYGAhBstwLx So, it expects a form-data style body with the given boundary Host: localhost:5000 Referer:http://localhost:5000/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 upload=FieldStorage%28%27sysdump%27%2C+%27Case_45815_sysdump-Woking- Bisley-20080702-163019.tgz%27%29case_number= But the request body is actually application/x-www-form-urlencoded -- Ian Bicking | http://blog.ianbicking.org -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: empty POST dictionary for post request when using webob.Request in middleware
Can you avoid touching req.POST or req.params? If you don't access those attributes, no parsing of the request body will happen. If you just access req.GET you should be safe. On Mon, May 18, 2009 at 12:57 PM, John Smallberries welch.quietple...@gmail.com wrote: Ian: I'm truly stumped (I'd already tried reading/stashing the body at once after seeing discussions about -1 content lengths, and also reading from environ['wsgi.input'], all with the same behavior). I'm not married to my particular code here -- what's the usual way someone succeeds in propagating a FieldStorage past WebOb middleware? The thing I'm writing does something interesting with GETs, and should pass POST's through unmolested. Wyatt: It's not a new request, it's a WebOb wrapper around the WSGI environ: http://pythonpaste.org/webob/reference.html#id1 -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: empty POST dictionary for post request when using webob.Request in middleware
Your request looks weird: On Fri, May 15, 2009 at 2:57 PM, John Smallberries welch.quietple...@gmail.com wrote: Logfile output from the above: 2009-05-15 12:45:31 INFO handling request POST /testform Accept: text/xml,application/xml,application/xhtml+xml,text/ html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Encoding: gzip, deflate Accept-Language: en-us Cache-Control: max-age=0 Connection: keep-alive Content-Length: -1 Content-Type: multipart/form-data; boundary= WebKitFormBoundaryGA7kzcYGAhBstwLx So, it expects a form-data style body with the given boundary Host: localhost:5000 Referer: http://localhost:5000/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 upload=FieldStorage%28%27sysdump%27%2C+%27Case_45815_sysdump-Woking- Bisley-20080702-163019.tgz%27%29case_number= But the request body is actually application/x-www-form-urlencoded -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: app engine - state of play - 0.9.7
The server always sets wsgi.multiprocess, but in the dev environment the processes aren't recycled that often so it's actually almost always okay (no worse than using it with paster --reload), but evalerror still disables itself. On Wed, May 6, 2009 at 1:35 PM, Mike Orr sluggos...@gmail.com wrote: On Wed, May 6, 2009 at 9:50 AM, Ben Bangert b...@groovie.org wrote: On May 6, 2009, at 12:54 AM, Wichert Akkerman wrote: I click on the + and get a javascript error. What type of environment? What wsgi server? I can see why it wouldn't work under GAE, since there's no guarantee you'll get back to the same process (it relies on a *single* long-lived process to ask for more debug info). The GAE problem also occurs in the development server. You get a cgitb traceback instead of the interactive traceback. Ian thinks WebError is disabling itself due to something in the environment, which may be related to David Wilson's workaround. Wichert's problem sounds completely different, and is not something I've encountered. I'm also curious what the Javascript error is. If it is a case of the server being restarted or a different server reached, the message would say that. Something like /_debug/123ABC is invalid (was the server restarted?). -- Mike Orr sluggos...@gmail.com -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Plugin architecture
eventually it got to be too big and we had to refactor that. A non-code feature that was important was a stylesheet. That is, an HTML page that listed how you use markup and CSS styles. This was the primary way visual consistency was attained. Without this consistency you can't really expect things not to look like a mish-mash, and serendipity of using the same styles without that is uncommon or at least error prone. Hmm... that most of what we did, I guess. Well, also stuff like workingenv which became virtualenv for package management, and stuff like sqlobject-admin for migration and paster make-config/setup-app for deployment -- some of those things never were really finished, which is why you might notice some inelegance. I think in terms of scope it was similar to Pinax. Django itself doesn't integrate in quite that way. You could of course build just this on Pylons as well. It wouldn't *be* Pylons, but you'd certainly be no worse off for using Pylons as a starting point. It always was fairly workable for one-off applications, it didn't involve any terrible conceptual overhead. Which is kind of true for Django too... just because it's more integration focused, you can still ignore that stuff and use it as a simple framework. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: ProfileMiddleware problem?
I think there's been some changes to the middleware and to the Python
profiling module, which may be leading to this (older versions of Python
required replacing sys.stdout to capture the profiling output, later
versions stopped requiring this hack). Maybe you changed your Python
version? Or upgraded Paste and are still using an older Python version.
On Tue, Apr 28, 2009 at 3:36 PM, Ross Vandegrift r...@kallisti.us wrote:
Hey everyone,
I noticed when shuffling between config files that my profiling setup
is busted. In my middleware.py:
# CUSTOM MIDDLEWARE HERE (filtered by error handling middlewares)
if config.get('profile'):
from paste.debug.profile import ProfileMiddleware
app = ProfileMiddleware(app, global_conf)
I used to get a yellow div at the bottom of the screen with the paster
profiling output. Now, I get an empty yellow div and the profiling
data goes to the console.
This isn't any major deal - just an oddness I noticed. Is there
something I need to change to use ProfileMiddleware?
--
Ross Vandegrift
r...@kallisti.us
If the fight gets hot, the songs get hotter. If the going gets tough,
the songs get tougher.
--Woody Guthrie
--
Ian Bicking | http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Pylons, HTTP 201 Accepted, Task Queues and Background threads
If you are thinking about user-visible long running tasks, maybe give a look at: http://pythonpaste.org/waitforit/ -- it seems like you are more thinking about APIs, but at least similar. FYI, I think there's actually an HTTP header to indicate when the client should poll next. On Tue, Mar 3, 2009 at 2:57 PM, kmw kochhar...@gmail.com wrote: Hi everyone, I'm trying to find some docs or perhaps old discussions about implementing a task queue within a pylons application. The scenario I'm trying to support involves a request coming into the app server to perform an action which takes a long time to complete, such as rebuilding an index or updating a value across hundreds of thousands of objects. My thought was to create a processing thread when the app is loaded. When I get the request I add the item to a synchronized queue (which the processing thread blocks on) and return a HTTP 201 Accepted to the client. The processing thread picks up tasks from the queue and they are completed in the order received. The 201 response also has an additional Location header to poll the status of the task. The question that remained was how to create and manage processing thread. I've read a couple of threads on this subject, and hunted around google a bit and found a couple of options: - http://groups.google.com/group/pylons-discuss/browse_thread/thread/e30fb912ca79b000/7cc1d4a6b1d9919d?lnk=gstq=background#7cc1d4a6b1d9919d - http://groups.google.com/group/pylons-discuss/browse_thread/thread/3e9dfda05af50634/bc914b96e2b96a1b?lnk=gstq=background#bc914b96e2b96a1b Now I'm leaning towards creating a process using the python multiprocessing module which interfaces like a thread but skips issues with the GIL and pylons thread management. However, I didn't find any information about how to manage the process lifecycle and allow it to shutdown gracefully when the server is stopped. I'd appreciate feedback on this approach and any pointers to resources that will allow me to hook into the app lifecycle and manage my subprocess as well. Hopefully I can get a working recipe out of this and put it all together in the pylons cook book for future reference. Thanks. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
appengine SDK 1.1.9 and appengine-monkey
Reportedly (http://code.google.com/p/googleappengine/issues/detail?id=61 and http://code.google.com/p/googleappengine/issues/detail?id=60) the appengine SDK (and presumably live environment) now include many of the pieces from appengine-monkey. This means that potentially appengine-monkey is not needed to run things like Pylons. Are there people using Pylons and appengine-monkey? If so, please test if you can remove the appengine-monkey monkeypatches. Removing import appengine_monkey from your runner script (probably paste-deploy.py) should do it. If there are problems, they should probably be listed in issue 60. Actually, if there aren't problems reports of that should also go in issue 60. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons reload signal?
On Wed, Feb 4, 2009 at 12:36 AM, Kevin Baker kba...@missionvi.com wrote: So are you saying that it is doing a restart when it detects a change... not just reloading the conf? If that is the case I guess I can just restart. I am trying to reload with as little impact on uptime as possible. With apache I do a /etc/init.d/apache2 reload rather than restart for the same effect. Yes, that's how it works. Apache actually works similarly, but it's a multi-process system -- when it reloads the configuration it makes sure all incoming requests are finished, holds any new incoming requests, and kills all the child processes and then new processes are made with the new configuration. If you have a process in front of the Pylons process you can avoid interruption, so long as the thing proxying to the process will do a retry. I don't think mod_proxy does this, but FastCGI/SCGI and maybe some other setups will do so. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons reload signal?
2009/1/30 Kevin Baker kba...@missionvi.com We have a production server with --reload flag off. We would like to have it reload when we update our code, rather than doing a stop start. Is there a way to signal the running pylons process to do a reload? The reloader is simply a monitoring process that restarts the subprocess when it dies, plus a thread that polls all the files for changes and exits the process when it sees a change. A possible alternative is to use --monitor, which uses that monitoring process, and then exit yourself when you want to reload. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: console tools
On Fri, Jan 23, 2009 at 2:31 AM, cropr ruben.dec...@gmail.com wrote:
I want to add some administrative console tools next to my 0.9.7
Pylons application (e.g. a backup/restore). I want to make use of
some parameter settings in the development.ini or production.ini,
but I don't need any wsgi stuff. What is the best and easiest way to
start up the console application
One more option:
paster request development.ini backup --output=backup.dump
routing and controller something like:
map.connect('/.command/:action', controller='commands')
class CommandsController(BaseController):
def backup(self):
assert request.environ.get('paste.command_request')
write_backup(request.params.get('--output', '-'))
return Response('Backup created')
--
Ian Bicking | http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: RegistryMiddleware is a major overhead
On Tue, Jan 20, 2009 at 1:37 PM, Ian Bicking i...@colorstudy.com wrote: On Tue, Jan 20, 2009 at 11:36 AM, Ben Bangert b...@groovie.org wrote: Similarly, other request handling operations such as creating the request object may also be redundant, because the user may not be interested in all the attributes of the request object. So wouldn't it be better to provide those things on-demand (that is using a call interface to get things such as params, etc) instead of creating all that stuff by default even when it may not be needed ? Sure, and its possible some other things in webob.Request might be more lazily done, though at the moment, most every attribute on it only actually does its work upon access. If you can see any specific locations in it that may be further optimized, that'd be great. If anyone does put together something to target webob performance specifically, that'd make the webob optimization happen a lot faster ;) Instantiation *shouldn't* be slow (I can't say for sure if that's true, but if it's not I'll want to fix that). And probably there's some features in Request that should actually be taken out (like environ_getter), that might be causing some overhead. But I'd rather work from empirical data, and I haven't gotten around to putting that together. Chris McDonough also noticed some speed issues with WebOb, so I put together a simple profiler: http://svn.pythonpaste.org/Paste/WebOb/trunk/tests/performance_test.py Based on this I've made a number of improvements to Response.__init__ and Request.__init__ to improve the base performance. This doesn't affect anything after initialization, but for a lot of cases these may be the only functions to be hit. (Well, setting values in Response.headers might be slightly faster) -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: RegistryMiddleware is a major overhead
On Tue, Jan 20, 2009 at 11:36 AM, Ben Bangert b...@groovie.org wrote: Similarly, other request handling operations such as creating the request object may also be redundant, because the user may not be interested in all the attributes of the request object. So wouldn't it be better to provide those things on-demand (that is using a call interface to get things such as params, etc) instead of creating all that stuff by default even when it may not be needed ? Sure, and its possible some other things in webob.Request might be more lazily done, though at the moment, most every attribute on it only actually does its work upon access. If you can see any specific locations in it that may be further optimized, that'd be great. If anyone does put together something to target webob performance specifically, that'd make the webob optimization happen a lot faster ;) Instantiation *shouldn't* be slow (I can't say for sure if that's true, but if it's not I'll want to fix that). And probably there's some features in Request that should actually be taken out (like environ_getter), that might be causing some overhead. But I'd rather work from empirical data, and I haven't gotten around to putting that together. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Is Pylons a meta-package ?
On Sun, Jan 11, 2009 at 3:19 PM, Tycon adie...@gmail.com wrote: I guess that means routes can be taken out if I remove the routes middleware and use my own url_for (which I was just about ready to do). So in your assessment a simple hello world on pylons using cherrypy instead of paster (that is my current config) is going to be as fast as just as an equivalent cherrypy (or pretty close, but not twice as slow) ? There's a category error here. There are a few Paste-Deploy-compatible web servers. paste.httpserver and CherryPy's servers are two examples (the two most popular for Pylons users). There's also the flup servers (which aren't http), Spawning, and... some other ones I can't remember now. Whether you choose paste.httpserver or CherryPy's server is up to you, it doesn't affect any other choice. They act almost identically (CherryPy is somewhat faster, paste.httpserver has some debugging tools... maybe there's some HTTP/1.1 features that one supports that the other doesn't, but I haven't kept track). Paste Deploy is a configuration setup to glue together middleware and other components into a single http-serving-wsgi-application. It also lets you select a web server. paster serve takes the Paste Deploy configuration and actually runs it. It's kind of like an app server, but a very small app server. There's not really any runtime over head to Paste Deploy and paster serve -- they just glue things together, but by the time you are actually serving HTTP they are finished with their jobs. -- Ian Bicking | http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: A more concise way to do it?
mk wrote:
Dalius Dobravolskas wrote:
2. In simple / naive usage mode it requires mixing HTML and code, which
That's not the case. Not sure there you get that from.
Oops, I wasn't clear on this issue: formencode.htmlfill does provide
some basic form manipulation, but in the form I don't like very much,
example from docs:
from formencode import htmlfill
form = 'input type=text name=fname'
defaults = {'fname': 'Joe'}
htmlfill.render(form, defaults)
'input type=text name=fname value=Joe'
Unless values of 'form' and 'defaults' vars are acquired from a place
different than controller code (from template? database?), this is
mixing view and controller. That's what I meant to mean.
This is mixing form-values-coming-in with form-values-coming-out. They
are symmetric. Your controller is the place you should handle both of
those values. Of course the form itself should come from a template, it
just doesn't in that example -- you should render a form template, then
fill it with htmlfill.
--
Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: waitfor it and pylons debugger, WAS: Running a program without waiting for it to finish
Jules Stevenson wrote: Hi Ian, I didn't notice this thread first time around, but you might find WaitForIt (http://pythonpaste.org/waitforit/) helpful for cases like these; you could write the code as blocking and let WaitForIt deal with the long-running aspect. (Assuming it runs for a long time, but eventually finishes -- if you need to interact with it over time you should stuff the process object in a module global) Thanks, this does indeed look like just the ticket. However I'm struggling to get this to work with Pylons correctly, specifically it seems to interfere with the debugger in the way that I have it set up [which is probably wrong]. To set it up I came across a post (http://www.mail-archive.com/paste-us...@pythonpaste.org/msg00213.html) on the paste mailing list which contained the following info: --- so then I tried to use waitforit with pylons, so I made a new pylons app and added this to my test.ini file: [app:main] use = config:development.ini filter-with = slow [filter:slow] use=egg:waitforit time_limit=2 poll_time=1 --- I don't think I even use test.ini, so I modded my development.ini file to look like this: snip [app:main] use = egg:ark full_stack = true cache_dir = %(here)s/data beaker.session.key = ark beaker.session.secret = somesecret sqlalchemy.default.url = sqlite:///%(here)s/data/project.db *filter-with = slow *[filter:slow] *use=egg:waitforit *time_limit=2 *poll_time=1 /snip With the * lines being the new additions [minus the asterisk of course]. This does work, and I can use the wait for it message etc, however if the pylons debugger needs to kick in it's now broken, with the following errors: Traceback (most recent call last): File c:\python26\lib\site-packages\paste-1.7.2-py2.6.egg\paste\evalexception\mid dleware.py, line 82, in simplecatcher_app return application(environ, start_response) File c:\python26\lib\site-packages\paste-1.7.2-py2.6.egg\paste\httpexceptions.py , line 636, in __call__ return self.application(environ, start_response) File c:\python26\lib\site-packages\paste-1.7.2-py2.6.egg\paste\evalexception\mid dleware.py, line 117, in application res = func(*args, **form.mixed()) File c:\python26\lib\site-packages\paste-1.7.2-py2.6.egg\paste\evalexception\mid dleware.py, line 140, in debug_info_replacement debugcount = int(debugcount) TypeError: int() argument must be a string or a number, not 'list' Any help on how to stop this? Hmm... I haven't seen this error, though generally it's better if WaitForIt is wrapped only around those parts of your app that are slow. I don't think Pylons controllers have a clear WSGI interface. That's too bad, they should. Here's a WSGI wrapper on a controller: class MyController(BaseController): ... def app(environ, start_response): return MyController()(environ, start_response) MyController = WaitForIt(app) I believe that will work, and then you can wrap just the controller that is likely to be slow. -- Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Best unit testing module for pylons REST api calls
Chris Miles wrote:
On 08/01/2009, at 5:51 AM, csismondo wrote:
I have a controller that I want to build unit test for, the controller
is a web-based REST api, and I would like to know what you guys would
recommend for a module.
I'm using the TestController that comes with a Pylons template project
for RESTful HTTP controller testing. This uses webtest as mentioned
by Jorge. In the tests you can just use calls like:
response = self.app.post(url('/new_app_submit'),
params=dict(app_name='testapp1', app_desc='Test app #1'))
response = self.app.put(url('/app/testapp1/purchases/user1/
productA'))
response = self.app.get(url('/app/testapp1/purchases'))
and test the response object for each case. e.g:
self.failUnlessEqual(response.status, '200 OK')
If you need a more thorough example of code just call out.
Note that WebTest automatically tests for a response code of 2xx or 3xx
-- 4xx or 5xx will raise an error. So you don't really need
failUnlessEqual, and you can always assert the response code like:
self.app.post(..., status=200) # e.g., 204 No Content would be an error
self.app.post('/random', status=404)
--
Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Looking at news, this is only in trunk: http://svn.pythonpaste.org/Paste/Deploy/trunk/docs/news.txt Try: easy_install PasteDeploy==dev Tycon wrote: PasteDeploy 1.3.2 Paste 1.7.2 According to (non)-easy-install these are the best match version, and it's already the active version in easy-install.pth, so hopefully that means I have the latest version in easy- install (=cryptic) speak. On Jan 5, 10:04 am, Ben Bangert b...@groovie.org wrote: On Jan 3, 2009, at 12:34 AM, Tycon wrote: but the PrefixMiddleWare also doesn't seem to be setting the WSGI environment url_scheme (nor request.scheme). The PrefixMiddleware code never looks up HTTP_X_FORWARDED_PROTO and doesn't set the url scheme in the wsgi environment. So that needs to be fixed, as well as made clear to users that they should include it (after it's fixed) if they use a reverse proxy even without a prefix. Hmm, I was under the impression that the latest PrefixMiddleware in Paste does take that into account. Which version of Paste are you using? Cheers, Ben smime.p7s 3KViewDownload -- Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: a better way to run multiple pylons apps?
eleith wrote: i've got a domain: example.com i want to run ten different websites (sub1.example.com, sub2.example.com sub10.example.com) a different pylons app will be running each of the 10 websites i'm proxying scgi from lighttpd (10 entries, each website running on port 5001, 5002 ... 5010) i have a script that can start all 10 pasters on bootup so, if i wanted to add an 11th website, i would 1) use up another port, 5011 2) add another proxy within lighttpd 3) modify my paster shell to start up yet another paster server on bootup is there a better way to go about this, so this scales better and can be easier to maintain? taking up another port, starting up yet another paster process seem like it can get a bit too resource intensive if all i want to do is just to run different websites (virtual hosts) You can use urlmap if you want, and host all the sites in the same Python instance. urlmap can do domain-based dispatch, like: [composite:main] use = egg:Paste#urlmap domain sub1.example.com / = config:sub1.ini domain sub2.example.com / = config:sub2.ini and so on, and each config file is like development.ini It's a little experimental, but there's a process dispatcher in wsgiproxy.spawn. It doesn't integrate with Paste Deploy, though it would be a nice bit of glue if it did (it'd be a matter of automatically starting an HTTP server serving a config file, with a PasteDeploy#prefix wrapper, and ports configured by the spawner itself). Of course you can also do ad hoc dispatch on your own, it's not too hard really. -- Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Running a program without waiting for it to finish
I didn't notice this thread first time around, but you might find
WaitForIt (http://pythonpaste.org/waitforit/) helpful for cases like
these; you could write the code as blocking and let WaitForIt deal with
the long-running aspect. (Assuming it runs for a long time, but
eventually finishes -- if you need to interact with it over time you
should stuff the process object in a module global)
tobycat...@gmail.com wrote:
hello everybody,
I am somewhat confused about the number of ways you can run an
external program from python/pylons.
I need my app to be able to compile and run a performance test. then
gather the results and display the results in a relevant way. the
tests are written in autoHotKey which is a windows scripting program.
so to run a test all i need to do is call the file from the command
line.
I have a controller that kicks off the test using the subprocess
module.
class PerformancetestrunnerController(BaseController):
def index(self):
self.compileTest('/perfTests/fx-quick-trade-verify.mako')
self.runTest('fx-quick-trade-verify.ahk')
return 'run'
def compileTest(self, testPath):
c.loopCount = 10
c.GBPUSD_buyButton = '100, 100';
render(testPath)
f = open('fx-quick-trade-verify.ahk', 'w')
f.write( render(testPath) )
f.close()
def runTest(self, testPath):
path = os.path.join('C:','Program
Files','AutoHotkey','AutoHotkey.exe')
process = subprocess.Popen([path, testPath])
This does start the test running, but the page does not finish loading
until the tests have finished.
the tests themselves can call back to the pylons app to record cpu and
memory metrics.
I guess there must be a NO_WAIT flag or something i can put in to
achieve my goal.
This page (http://docs.python.org/library/subprocess.html) suggests
pid = Popen([/bin/mycmd, myarg]).pid
As a no_wait example, but that didn't work for me either.
if any one has any ideas how i can achieve this, i await with baited
breath.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Selective bypassing of Error middleware in Pylons 0.9.7?
Domhnall Walsh wrote:
Hi there:
Hopefully you guys can help me. I'm working on an application that needs
to be able to selectively output JSON based on whether the submitted
requestion specifies application/json in the request's 'Accept:'
headers. I had a mechanism that worked okay in Pylons 0.9.6 based on a
custom error_mapper in config/middleware.py, wrapped up in a nice little
function I could call, but due to changes in how this works in Pylons
0.9.7 (I'm using RC4 on Python 2.5.1), which I've had to upgrade to for
unrelated reasons, I'm a bit lost. I've found references to being able
to do this by setting an environment variable
('pylons.status_code_redirect') in the docstrings for
pylons.middleware.StatusCodeRedirect but I can't figure out how to apply
this selectively rather than all the time. Can anyone shed some wisdom
on this?
Well, the middleware does try not to respond with a full response when
it gets an XMLHttpRequest. I tells this because of X-Requested-With:
XMLHttpRequest. Another thing that suppresses the full response is a
GET variable _. If you want, we would accept a patch that checks the
Accept header and also uses that to give shortened errors (you could
look for those other checks as a place to introduce a new check).
--
Ian Bicking : i...@colorstudy.com : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Wichert Akkerman wrote: Previously cropr wrote: I don't use FormEncode. It is based on a very common design mistake made by a lot of programmers, who think one can better generate html from code. When a graphical artist designs the layout of a web page, he uses tools who speak html, css and javascript, but no python (or Perl, Java, C++, ...). While I agree FormEncode is very far from ideal, your argument does not make sense to me. FormEncode does not generate markup at all unless you explicitly tell it to. I do exactly what you describe: hand-written markup written by a designer, with FormEncode on the backend only doing decoding and validation. Not only doesn't it generate markup unless you tell it to, it won't even generate markup if you *do* tell it to ;) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Django or Pylons - comparison details
Wichert Akkerman wrote: Previously Alex Marandon wrote: 2008/12/6 zunzun [EMAIL PROTECTED]: Seems like I should use Django? Or should it be Pylons instead? Here is the advice of an average programmer with no emotional involvement in any of these projects. I think it depends on your background. The Pylons ecosystem is very powerful but it's quite complex and not really suitable for beginners. If it's going to be the first web framework you use, you should probably stick with Django or even better Rails. grok might also be a good choice. I'm not quite sure of repoze.bfg is quite there yet, but it is shaping up to be another excellent candidate as well. Grok over Pylons? I don't think Grok is really any less complex. Doing basic stuff isn't particularly hard in Pylons, is it? There's no reason you have to use FormEncode, AuthKit, or any of those other pieces unless you want to, and if you are beginner to Python or web development you might off avoiding those pieces and just writing your own ad hoc code. Understanding Pylons will be a lot easier for you if you've spent time understanding a framework in any language. If you've written your own ad hoc PHP framework, for instance, or spent time spelunking in Rails code... that experience should help you recognize some of what's going on in Pylons. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Formencode Schema instantiation.
zepolen wrote: Say you make a class based on formencode Schema. class TestSchema(formencode.Schema): pass TestSchema.to_python will always refer to a single instance whereas TestSchema().to_python will create a new instance. Is there any downside from using the first one, eg. thread safety, assuming you don't use any of the mutating methods like add_field, and just use the to_python method? No, there's no problem, in fact TestScheme.to_python just instantiates the class and then calls to_python on the instance. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Testing tool to simply form session interaction
Randy Syring wrote:
I would like to be able to test my web applications from the
perspective of an actual user. Are there any tools that would let me
do something like:
c = Client(myapp)
app = TestApp(myapp)
r = c.get(/user/login)
r = app.get('/user/login')
r.checkfor('User Login')
r.mustcontain('User Login')
r.checkfor('enter credentials')
r.mustcontain('enter credentials')
r.set('username', 'foo')
r.form['username'] = 'foo'
r.set('password', 'bar')
r.form['password'] = 'bar'
r2 = c.submit(r)
r2 = r.form.submit()
And... I don't feel like translating the rest, but it's all just
different names for the stuff in WebTest, which is what Pylons sets up
for its tests by default.
r2.checkfor('login succesful')
r = c.get(/uploadfile) # at this point, the user's session from the
above login would be in effect
r = c.setfile('toupload', open('myfile.txt'))
r2 = c.submit(r)
r2.checkfor('file uploaded')
etc.
Obviously, the API would vary, but I hope you get my drift.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: End URLS in slash?
Mike Orr wrote: 1) Serve /foo as a container and let /foo/ not exist, which is what most Pylons apps do. 2) Redirect /foo to /foo/. Either is fine (you can have a redirect for 1 too). The most important thing is just not to be ambiguous. And you should probably do redirects. 3) Serve identical content for /foo and /foo/. Not uncommon but VERY BAD. Don't even consider doing this. 4) Serve different content for /foo and /foo/. Uncommon BUT ALSO BAD. Zope 2, in a fit of cleverness, does this -- adding base href to one of those so the links work equivalently for either. It's a horrible awful thing. Resources and URLs should be one-to-one. Ambiguous URLs are one of those things in Zope that have scarred me, and seeing how hard that makes other things has made me sensitive to ambiguity elsewhere. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Can we move the tests folder inside the pylons folder?
Mike Orr wrote: On Tue, Nov 18, 2008 at 2:02 PM, Matt Wilson [EMAIL PROTECTED] wrote: On Nov 18, 12:51 pm, Ian Bicking [EMAIL PROTECTED] wrote: Matt Wilson wrote: After easy_installing Pylons, my site-packages folder has an easy- install.pth file that points to my Pylons-0.9.7egg folder. Inside that egg folder, I've got these directories: $ ls ~/virtualenvs/scratch/lib/python2.5/site-packages/Pylons-0.9.7rc3- py2.5.egg/ EGG-INFO pylons tests Hrm... the reason I typically put tests outside of the package is to skip installing them. Should Pylons just not install that package? What is the downside of installing tests underneath pylons? It might be better to have the tests and not need them instead of the other way around. The downside of course is disk space. (And on App Engine, the 1000-file limit.) I don't think a best practice has emerged on where to put the tests, because some people put them inside the package and others outside. My inclination would be to put them inside, because a top-level 'tests' is rather presumptive. (This is the most important package in the world, and no other package would have tests.) Well, with py.test it didn't care about __init__.py, so it wouldn't be a test at all. But then with Python 2.6 that isn't enough to keep it from being a package, and nose cared about importability so a lot of them have __init__.py... which messes it up. But still that tests/ directory should never be installed if it is top-level. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Javascript library
cropr wrote: - after that I tested jQuery, fast and concise but does not have UI widgets on its own. If you don't need widgets , this is the very good choice. The UI addon is a less quality than jquery, without a good rich text editor. So I looked around for more I think expecting a WYSIWYG editor and general-purpose library to be the same thing isn't really important. It'd be better to choose these entirely separately. (I have read that TinyMCE has started trying to use libraries like jquery internally, but found that it didn't really make any big difference in the code size -- WYSIWYG code is very different in scope than typical libraries) - Yui is bigger than jQuery, but not bloated as extjs. Good documentation. For me the biggest asset of YUI is the hosting service. It offloads my small webserver at home. I did not experience any issues with the rich text editor FYI, google is hosting libraries like jquery (e.g., http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: ProfileMiddleware logging
Pavel Skvazh wrote: I'm having problems integrating it.. Anyway, isn't paste.profile supposed be bale to log everything it outputs to the console to the log file? Probably I've missed something along the lines, but it looks like it logs list of my packages, which makes very little sense. from paste.debug.profile import ProfileMiddleware app = ProfileMiddleware(app, log_filename='/profile.log') app = RoutesMiddleware(app, config['routes.map']) app = SessionMiddleware(app, config) app = CacheMiddleware(app, config) No matter if I plug it first or last, it logs everything the way it's supposed to into the console and something meaningless to the log file. The log file is just some stats that is then parsed by hotshot.stats -- you could potentially parse it entirely separately. But I think it also clears it every request. I'm afraid there's no configuration in it for actually printing stats elsewhere or aggregating statistics. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: ProfileMiddleware logging
Pavel Skvazh wrote: Following the general guidelines I've added this to the middleware.py app = ProfileMiddleware(app, log_filename='profile.log.tmp') The file was created, but the content is not what I've expected. It's a binary file.. hotshot-version 51218 requested-frame-timings yes requested-line- events no requested-line-timings no platform win32 executable D:\Python25\python.exe executable-versionB2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] reported- performance-frequency 3579545 current-directory D:\Pylons\rusbiz \trunk sys-path-entry D:\Pylons\rusbiz\trunk sys-path-entry D: \Python25\Scripts sys-path-entry2D:\Python25\lib\site-packages\myg Is there a way to log what this middleware does to the file and not the console? You might want to look at repoze.profile, which is very similar but might work a little more how you want. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Zipping Pylons components on App Engine
Ben Bangert wrote: On Oct 24, 2008, at 2:19 AM, Mike Orr wrote: lib/python2.5/site-packages/Pylons-0.9.7rc2-py2.5.egg 146 I almost have the latest Pylons zip-safe. I was able to modify PasteScript so that template directories can be zipped, and I got that bit working. I don't think the Static URL parser supports zip resources though, so the error pages bit didn't work. Once the new PasteScript is released, I'll update Pylons to use the new tuple syntax for the templates, then its just a matter of fixing the StaticURLParser, and the Pylons package will be fully zip-safe. There's a paste.urlparser.PkgResourcesParser that serves via pkg_resources instead of files. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Zipping Pylons components on App Engine
Mike Orr wrote: For reference, these are the biggest hogs in terms of number of files. (With manual sorting afterwards. *.pyc files were removed prior to count.) Incidentally, this opens up an issue: eggs normally contain .pyc files, but GAE will never load .pyc files so when you upload a zip with those in it it's a waste. But maybe not an important waste so long as you stay under 1MB. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Zipping Pylons components on App Engine
Mike Orr wrote: On Fri, Oct 24, 2008 at 9:32 AM, Ian Bicking [EMAIL PROTECTED] wrote: Mike Orr wrote: For reference, these are the biggest hogs in terms of number of files. (With manual sorting afterwards. *.pyc files were removed prior to count.) Incidentally, this opens up an issue: eggs normally contain .pyc files, but GAE will never load .pyc files so when you upload a zip with those in it it's a waste. But maybe not an important waste so long as you stay under 1MB. I believe the skip_files regex is set to ignore .pyc files when uploading. Yes, but it can't skip the .pyc files inside a zip/egg file. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Putting DELETE's params into request.POST
Sok Ann Yap wrote: I noticed that since version 0.9.3, PUT's params will be put into request.POST by WebOb. So, I wonder if DELETE will be threated the same? No. I was reluctant to allow this for PUT, but definitely am against it for any other HTTP methods. My use case: pylons.decorators.secure.authenticate_form only check for request.POST. I have a secure_form with method='delete' and want to test it, but there doesn't seem to be a way to pass the authentication token through self.app.delete into request.POST. This is similar to http://pylonshq.com/project/pylonshq/ticket/482 By the way, I used to have some ugly workaround to make self.app.put works with pylons.decorators.validate, by parsing wsgi.input into request.params and then set post_only=False. Sure glad I don't have to do that anymore :) I'm not sure why authentication tokens are only coming from wsgi.input, but that's the problem -- you should be able to set something in the environment to simulate authentication, and if not then that's a bug in the authentication system. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Paster/CherryPy production configuration
Kamil Gorlo wrote: So there is no problem, that for one Paster there is only one Python interpreter (maybe I do not understand GIL correctly)? Using processes despite Python threads is not better in your opinion? paster serve just starts a server -- the server doesn't have to be single-process. Flup includes some forking servers (for FastCGI, SCGI, AJK), and I believe the Spawning server should also be usable and has options to fork processes. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Freezing a Pylons app
Christopher Barker wrote: Mike Orr wrote: We're testing it right now. I'm cc'ing my colleague who's involved more directly with it. That would be me. I'm trying to bundle up a pylons based app with py2app on OS-X. I've run into a problem with Paste. The issue is that paste (and paste.deploy, and paste.script) is set up as a setuptools namespace package. Another strategy might be to use pyinstall, which will install these packages in a flat filesystem layout, so namespace packages won't really be important (that is, all the Paste packages will live in site-packages/paste/*). It still puts in .egg-info directories, so pkg_resources can see all the egg metadata (if you include those directories in py2app). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: temporary upload location
Dunk Fordyce wrote: Hello, When uploading files to my pylons app files are being put in /tmp. Is it possible to change this location? Im not 100% sure if this is a pylons thing or an apache setting ( or maybe even mod_wsgi? ). Unfortunately the /tmp dir on our server is mounted on quite a small partition. I think the cgi module actually saving those files, and it is probably just using tempfile or something which has its own mechanism to figure out the temp dir (and I don't really know what it is). If you look at the source there might be an environmental variable or something that you can set to control that. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: temporary upload location
Audrius Kažukauskas wrote: You can do this somewhere in the beginning of paste.request module: class MyFieldStorage(cgi.FieldStorage): def make_file(): ... # Your code here cgi.FieldStorage = MyFieldStorage It's a bit hacky, but it works (I tested it myself). BTW, maybe Paste author (it's Ian Bicking, right? :-) could come with more convenient way (public API calls?) to control this without the need of code modification in paste.request? That's possible, but looking at the source of tempfile it uses the environmental variables $TMPDIR, $TEMP, and $TMP to figure out where to put temporary files, and setting those values should be easy in comparison to these other techniques. Patching cgi.FieldStorage would allow for more fine-grained control (just where uploads go, instead of all temp files), but I'm not sure how important that really is. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: temporary upload location
Audrius Kažukauskas wrote: On Fri, 2008-09-26 at 12:52:49 -0500, Ian Bicking wrote: Audrius Kažukauskas wrote: You can do this somewhere in the beginning of paste.request module: class MyFieldStorage(cgi.FieldStorage): def make_file(): ... # Your code here cgi.FieldStorage = MyFieldStorage It's a bit hacky, but it works (I tested it myself). BTW, maybe Paste author (it's Ian Bicking, right? :-) could come with more convenient way (public API calls?) to control this without the need of code modification in paste.request? That's possible, but looking at the source of tempfile it uses the environmental variables $TMPDIR, $TEMP, and $TMP to figure out where to put temporary files, and setting those values should be easy in comparison to these other techniques. Patching cgi.FieldStorage would allow for more fine-grained control (just where uploads go, instead of all temp files), but I'm not sure how important that really is. OK, my use case: Web app lets upload big files (let's say, up to 100 MiB) and keeps them for some time. Right now they go to /tmp and it could be changed with environmental variables, as you said. But the problem is that files created by tempfile.TemporaryFile can only be read from or written to (at least in POSIX or Cygwin systems). You can't *move* them, only copy from them. And the saddest part is, they disappear when closed. Hence you must write data to some other file. So information is copied twice: when uploading to the temporary file and after that to some permanent file. If web app is used more intensively or files are getting bigger, this is inefficient. It's not high on my list of issues, but I can see your use case. Putting files in the right place to start with seems infeasible, but being able to move them around later seems reasonable (and controlling what directory they are written to, so you can keep them on the same device). I'd accept a patch, probably to WebOb. Somewhat relatedly, someone recently did a rewrite of cgi, that might be worth thinking about: http://mail.python.org/pipermail/web-sig/2008-September/003587.html -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Must myapp.egg-info folder be present to run?
mario ruggier wrote: python setup.py egg_info running egg_info unrecognized .svn/entries format; skipping . writing requirements to myapp.egg-info/requires.txt writing myapp.egg-info/PKG-INFO writing top-level names to myapp.egg-info/top_level.txt writing dependency_links to myapp.egg-info/dependency_links.txt writing entry points to myapp.egg-info/entry_points.txt writing paster_plugins to myapp.egg-info/paster_plugins.txt Traceback (most recent call last): File setup.py, line 39, in module , File /usr/local/lib/python2.5/distutils/core.py, line 151, in setup dist.run_commands() File /usr/local/lib/python2.5/distutils/dist.py, line 974, in run_commands self.run_command(cmd) File /usr/local/lib/python2.5/distutils/dist.py, line 994, in run_command cmd_obj.run() File build/bdist.linux-i686/egg/setuptools/command/egg_info.py, line 171, in run File build/bdist.linux-i686/egg/setuptools/command/egg_info.py, line 252, in find_sources File build/bdist.linux-i686/egg/setuptools/command/egg_info.py, line 306, in run File build/bdist.linux-i686/egg/setuptools/command/egg_info.py, line 333, in add_defaults File build/bdist.linux-i686/egg/setuptools/command/sdist.py, line 45, in walk_revctrl File build/bdist.linux-i686/egg/setuptools/command/sdist.py, line 52, in _default_revctrl File build/bdist.linux-i686/egg/setuptools/command/sdist.py, line 98, in entries_finder NameError: global name 'log' is not defined (But if I then try to run the app again, it does run, and all seems ok...) Any ideas where this last error might be coming from? And, must the egg_info folder be present for the pylons app to run? I think this is a bug in Setuptools, fixed on Setuptools trunk (easy_install setuptools==dev) and related to svn 1.5 or something. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Cron jobs
Pavel Skvazh wrote: Thanks everyone! That's just what I need. I just expected it will access already lauched application instead of running other instance. Works great, but still wondering if it'd be better to just launch a controller of running App instead of launching it again which takes quite some time on my machine. If you want to access the already-running app, just do wget http://localhost:5000/cron -- or maybe use something like webcron.org. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Cron jobs
Pavel Skvazh wrote:
There seam to be different ways to get cron jobs with Pylons.
In my case model has to be accessible in it.
Found three articles on the wiki describing different approaches,
which is rather confusing
http://wiki.pylonshq.com/display/pylonscookbook/Cron+jobs+and+command-line+utilities
This article describes paster request as a future possibility, but
it's been implemented for a while. That means you can do:
paster request config.ini /cron
and that will run the controller associated with /cron. You can check
environ.get('paste.command_request') to make sure the request originated
from paster request, if you don't want the command to be publicly
available via HTTP.
This runs all middleware, and so it also sets up all the configuration
just like a normal request.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: paster email notifications
matei wrote: Hi is there any way to authenticate to an email server by providing some login credentials in development.ini? The automatic email error notifications works fine when my mail server was on the same host as the app, but now it has moved.. There are some extra settings you can use for SMTP: smtp_username smtp_password smtp_use_tls -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Yet another high-performance WSGI server
Ben Bangert wrote: On Aug 14, 2008, at 6:23 PM, Cliff Wells wrote: Possible replacement for Paste#http: http://pypi.python.org/pypi/Spawning/0.7 A speed comparison of Django+mod_wsgi vs Spawning that lacks enough info to be labeled definitive, but interesting nonetheless: http://www.eflorenzano.com/blog/post/spawning-django/ My own tests have been limited to changing a fresh Pylons project's test.ini to use egg:Spawning rather than egg:Paste#http and verifying that Pylons runs, so YMMV ;-) I've gotten similar results to the benchmark there for a Pylons app. Though there's a few things Paste#http does that neither PasteScript#cherrypy (faster than Paste#http), nor spawning do. Might help to illustrate the differences: Paste#http - Uses thread-pool - Can launch additional threads in the event threads are all taken - Can kill 'stuck' threads to avoid server stall - Can recycle threads after configurable amount of requests (helps with possible memory leaks) At least potentially Spawning should be able to do all of these, but using subprocesses instead (probably with greater reliability). mod_wsgi already does this, in effect, using the Apache process management. I believe, but I'm not sure, that Spawning reads the entire input (asynchronously) before calling the WSGI application, which would also allow it to support many more incoming uploads. Generally it has at least the potential to more gracefully handle lots of nasty overload cases. Also, if you don't use subprocesses or threads with it, you can run your WSGI application asynchronously. This won't work if you use databases or even files, but for some applications it might provide interesting possibilities -- specifically lots of concurrent requests, or things like Comet-style applications that push events. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: response status when form validation fails
Sok Ann Yap wrote: Currently, the validate decorator always return 200 OK when validation fails. I think 400 Bad Request is more appropriate here, so that it will be easier for non-browser application to interact with the pylons app. Maybe we can add a parameter to @validate that is defaulted to 200, to make it backward compatible. Well, the thread is old and kind of closed, but just for the record I think a 400 Bad Request code is entirely reasonable for this case, and a good use of that response code, with little ill effect (assuming, as was noted, that you respond with a large enough body to avoid the IE error page). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: setup-app and filter-with
Sean Davis wrote: I have an application that I am trying to filter through an apache reverse proxy. That seems to be working, but paster setup-app fails with: The section 'main' is not the application (probably a filter). You should add #section_name, where section_name is the section that configures your application Hmm... this looks like it's probably a bug in PasteDeploy and/or PasteScript. As a workaround, if you use: [app:solexa] use = egg:SolexaDB [filter:prefix] use = egg:Paste#prefix [pipeline:main] pipeline = prefix solexa Then setup development.ini#solexa it'll work. I am using 0.9.6.2 and the configuration sections look like: [app:main] use = egg:SolexaDB # set up to allow proxying via apache filter-with=proxy-prefix # Note that the prefix should be set to the path used # in the apache proxy configuration [filter:proxy-prefix] use = egg:PasteDeploy#prefix prefix = /pressa Any ideas? Thanks, Sean -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paster trouble
I'm not sure, but I suspect it's not paster that's the problem, but
perhaps that MySQLdb wasn't installed correctly somehow, and that is
causing Setuptools to barf. That, and/or in you application you have
something in YourApp.egg-info/paster_plugins.txt that is referencing a
package that requires MySQLdb, but that driver isn't installed (or if
you are using a virtual env, might not be installed in that environment).
morecowbell wrote:
greetings,
i've been trying to get through the pylons example but got stuck at
executing
the first paster command and was hoping somebody can tell me what's
going on.
i'm on mac 10.4, intel and ppc, got the regular python 2.5 set up and
pylons in a
virtual environment. in my global environment, i got cherrypy, django,
httlib2, pyqt4,
mysqldb 1.2.2c1, setuptools 0.6c8, sql alchemy 0.46; in the virtual
env i got the
standard pylons libs and setup tools 0.6c8.
to the problem at hand: somewhere is a dependency on mysqldb and i
can't figure
out where. (i installed mysqldb manually with -build and -install):
bb-iMac:~ bebo$ ~/env/bin/paster create -template=pylons HelloWorld
Traceback (most recent call last):
File /Users/bebo/env/bin/paster, line 8, in module
load_entry_point('PasteScript==1.6.3', 'console_scripts', 'paster')
()
File /Users/bebo/env/lib/python2.5/site-packages/PasteScript-1.6.3-
py2.5.egg/paste/script/command.py, line 68, in run
commands = get_commands()
File /Users/bebo/env/lib/python2.5/site-packages/PasteScript-1.6.3-
py2.5.egg/paste/script/command.py, line 110, in get_commands
plugins = pluginlib.resolve_plugins(plugins)
File /Users/bebo/env/lib/python2.5/site-packages/PasteScript-1.6.3-
py2.5.egg/paste/script/pluginlib.py, line 81, in resolve_plugins
pkg_resources.require(plugin)
File /Users/bebo/env/lib/python2.5/site-packages/setuptools-0.6c8-
py2.5.egg/pkg_resources.py, line 626, in require
File /Users/bebo/env/lib/python2.5/site-packages/setuptools-0.6c8-
py2.5.egg/pkg_resources.py, line 524, in resolve
pkg_resources.DistributionNotFound: MySQL-Python-1.2.1-p2-py2.5: Not
Found for: MySQL_Python-1.2.1_p2-py2.5 (did you run python setup.py
develop?)
bb-iMac:~ bebo$
this is the easy-install.pth for the virtual env:
import sys; sys.__plen = len(sys.path)
./setuptools-0.6c8-py2.5.egg
./PasteDeploy-1.3.2-py2.5.egg
./Pylons-0.9.6.2-py2.5.egg
./Mako-0.2.2-py2.5.egg
./nose-0.10.3-py2.5.egg
./decorator-2.3.0-py2.5.egg
./simplejson-1.9.2-py2.5-macosx-10.5-i386.egg
./FormEncode-1.0.1-py2.5.egg
./PasteScript-1.6.3-py2.5.egg
./Paste-1.7.1-py2.5.egg
./Beaker-0.9.5-py2.5.egg
./WebHelpers-0.6-py2.5.egg
./Routes-1.9.2-py2.5.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:];
p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p
+len(new)
and for the setuptools.pth
./setuptools-0.6c8-py2.5.egg
given the enormous amount of time i spent chasing this down, to no
avail, it must be something annoyingly trivial.
thx for your help
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Can't install Pylons on Mac
Mike Orr wrote: Tried to install Pylons 0.9.7 beta on a colleague's Mac and got a funny error: $ easy_install -f http://pylonshq.com/download/0.9.7 -U Pylons Processing Pylons error: couldn't find a setup script in Pylons I'm not sure if virtualenv is creating a corrupted environment or what. go-pylons.py gave up with the same error. The system is Mac OS X 10.4. Do you have a Pylons directory? Maybe it is confusing Pylons the package with Pylons the directory. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebHelpers 0.6 released
Christoph Haas wrote: On Freitag, 11. Juli 2008, Mike Orr wrote: On Fri, Jul 11, 2008 at 9:43 AM, rcs_comp [EMAIL PROTECTED] wrote: in html.tags the form function has 'POST' for the default method, which is invalid xhtml. I changed it to: def form(url, method=post,... and all is well. Is it really? Does the browser convert it to POST before sending the HTTP request? Just want to make sure I don't break anything before lowercasing it (and all the other methods in the function). I second rcs_comp (/me donates his parent a few bucks to give him a real name). I use method='post' everywhere in my code because uppercase attributes aren't xhtml'ish. That reminds me that I wanted to open a ticket for that one. :) Uppercase attribute... values? What does XHTML care about the values? Apparently the DTD does specify lower-case values. XHTML is totally nutty. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebHelpers 0.6 released
Mike Orr wrote: So are applications actually breaking with form method=POST ? Or is this an issue of formal correctness only? Formal correctness of XHTML 1.0 strict only. Well, maybe if you serve your content as XHTML 1.0 strict the browser might barf on that. But if it does, it only barfs because you've asked it to. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: WebHelpers 0.6 released
Mike Orr wrote: On Fri, Jul 11, 2008 at 1:09 PM, Ian Bicking [EMAIL PROTECTED] wrote: XHTML is totally nutty. I've been feeling better about XHTML since I started using DocBook. I'm quite glad there's a simple XSLT transformation from DocBook - XHTML to read the text without having to use a WYSIWYG editor (all of which seem to be commercial and/or Java). Converting to HTML 4 seems to be more problematic. Likewise, when I get tired of DocBook's verboseness, I think about making a XHTML - DocBook converter, which would be more difficult than going from HTML. Although I suppose not that difficult with BeautifulSoup. Generally all XSLT engines have the ability to output HTML. I can't remember the invocation, but it's pretty simple. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: supervisor questions
Shannon -jj Behrens wrote: Hi, I'm looking at http://wiki.pylonshq.com/display/pylonscookbook/Monitor+Pylons+application+with+supervisord. Huh... I'm getting a 404...? I have a few questions: 1. Why does it use a manually created server.py instead of using paster like normal? I use paster serve (no --reload, --monitor, --daemon, any of which would mess it up). 2. Does anyone have an rc script to start supervisor under Ubuntu? Huh, actually no. It did occur to me that supervisor should ship with such a thing. Incidentally we use a per-site supervisord. 3. Is anyone doing any fancy log rotation or are the defaults reasonable? The defaults have seemed reasonable to me (though there's no cleanup or compression AFAIK, just rotation). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: supervisor questions
Ian Bicking wrote: 1. Why does it use a manually created server.py instead of using paster like normal? I use paster serve (no --reload, --monitor, --daemon, any of which would mess it up). Incidentally, one thing I don't think is all that well explained (at least in the supervisor docs), is that shell scripts must end with: exec paster serve production.ini So, if you want a shell script (e.g., to setup the environment) you have to be sure to use exec at the end; this makes paster replace the shell process. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best way to get user's IP address in pylons?
Jonathan Vanasco wrote: On Jul 3, 4:42 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Possibly better: request.environ.get(X_FORWARDED_FOR, request.environ[REMOTE_ADDR]) maybe someone can make a middleware or pylons patch + config setting that migrates X_FORWARDED_FOR to REMOTE_ADDR this is the one i maintain for mod_perl http://search.cpan.org/dist/Apache2-xForwardedFor/lib/Apache2/xForwardedFor.pm I was going to say that PrefixMiddleware already did this, but apparently it didn't. It does now in Paste Deploy trunk. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: best way to get user's IP address in pylons?
Shannon -jj Behrens wrote: On Thu, Jul 3, 2008 at 2:05 PM, Ian Bicking [EMAIL PROTECTED] wrote: Jonathan Vanasco wrote: On Jul 3, 4:42 pm, Wichert Akkerman [EMAIL PROTECTED] wrote: Possibly better: request.environ.get(X_FORWARDED_FOR, request.environ[REMOTE_ADDR]) maybe someone can make a middleware or pylons patch + config setting that migrates X_FORWARDED_FOR to REMOTE_ADDR this is the one i maintain for mod_perl http://search.cpan.org/dist/Apache2-xForwardedFor/lib/Apache2/xForwardedFor.pm I was going to say that PrefixMiddleware already did this, but apparently it didn't. It does now in Paste Deploy trunk. I remember submitting a pretty decent patch for this a long time ago. I think we had philosophical differences about whether to read the headers in attributes, or rewrite the environment, and I was on the rewrite side. And... wasn't it X-Forwarded-Server? -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Dynamically Choosing A Rendering Engine
Jonathan Vanasco wrote:
well a few things i'd suggest from previous exploits in other
languages ( btw, have you looked into pylons.templating ? )
- have render take a format argument to override
- instead of pulling off the config, why not just read the file
extension ? pretty much every templating engine has claimed their own
extension, and stopped using .tmpl or .html ; the only one i can think
of that doesn't follow that mentality is tal, which has multiple
render implementations.
Genshi tends to use .html, I think. It's just too ambiguous.
- and from personal preference, i'd rename render to render__mako
render__genshi . i'd use two underscores, so one underscore is
available for non engine defs
so...
render('file.mako')
would realize its a mako file by noticing the .mako
if i wanted to override, i could do
render('file.mako', engine=genshi)
or
global_reder_override('genshi')
render('file.mako')
Right now you could define this in an ad hoc way with:
def render(*args, **kw):
if 'engine' in kw:
engine = kw.pop('engine')
else:
engine = 'mako'
return renderers[engine](*args, **kw)
renderers = dict(mako=render_mako, genshi=render_genshi)
It doesn't seem like that common of a need... this renderer could itself
be provided too if it is a common desire (maybe as a class with
renderers as an instance variable).
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: jsonp support
Jonathan Vanasco wrote:
this thread had me thinking...
it would be really neat if there were a way to cancel out the jsonify
decorator in a function
ie:
@jsonify
def index(self):
rVal= { 'status': 'error' }
self.jsonify_cancel()
return rVal
i can't remember why i wanted to do this, but i had a good reason to
the other day!
Maybe something like this:
class HTTP_OK(HTTPException):
code = 200
message = 'OK'
raise HTTP_OK('some message')
A little weird. But a good way to break out of the decorators.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: jsonp support
Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: jsonp support
Shannon -jj Behrens wrote: On Tue, Jun 17, 2008 at 2:55 PM, Ian Bicking [EMAIL PROTECTED] wrote: Shannon -jj Behrens wrote: I'm using the jsonify decorator. It'd be nice if that decorator were updated to *automatically* support the jsonp parameter http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Hence, if I request a URL like http://localhost:5000/api/service?jsonp=foo, and jsonify is used, it should automatically wrap the JSON in foo(). Isn't JSONP a security concern if you aren't exposing something intended to be public? That is, you can use JSONP to read data using the browser's credentials, which is sometimes okay and sometimes not. So optionally turning it on is nice, but always turning it on is dangerous. I can't comment on that. My service is a public service. Perhaps you can explain what you mean in more detail. Bob talks about security a bit on his blog post: http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/. Let's say I have a JSON method that returns your list of friends. That's private, and the method is restricted based on authentication. But any random website could include this: script src=http://somesocialnetwork.org/api/friends?jsonp=readFriends;/script and then it would be able to read your private list of friends if you had logged into somesocialnetwork.org. Simply requiring people to explicitly turn on jsonp support, with a warning that only public data should be exposed that way, would address that issue. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons-based JSON-RPC service?
Here's an example using WebOb without Pylons: http://pythonpaste.org/webob/jsonrpc-example.html A useful addition to this would be to use Routes to select the service end point. Once the endpoint is instantiated I think a more pure-WSGI approach (like in the tutorial) makes more sense than using the Pylons Controller. But the Pylons Controller itself is just a WSGI application (-factory -- instances are the WSGI applications), so you can just replace the controllers. KJ wrote: Would Pylons be a good choice for implementing a JSON-RPC-based web service? If yes, can someone point me to a good example? (Actually, I'd be interested in seeing examples of any Pylons-based web service, even if it doesn't use JSON.) If not what other framework would more suited for this task? TIA! KJ -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Truncating an html string safely
Mike Orr wrote: On Thu, Jun 5, 2008 at 11:56 AM, TJ Ninneman [EMAIL PROTECTED] wrote: On Jun 5, 2008, at 12:59 PM, Matt Feifarek wrote: I'd like to use something like the truncate feature of webhelpers on html data that's being pulled in from an ATOM feed. If I just use a simple truncate, it might leave some html tags opened (like a div without a /div) which is Bad. I figured that this was a common-enough task that I'd ask some experts before trying to roll my own solution. It seems like the kind of thing that might be hidden within the standard library somewhere, below my nose, but outside of my ability to discover. I've found this: http://code.djangoproject.com/browser/django/trunk/django/utils/text.py Looks to be about the right thing, but I'd rather not be dependent on all of Django to do this. Perhaps some ElementTree or LXML wizard knows a quick hack? Thanks! I've had excellent luck stripping HTML with the following: http://www.aminus.net/browser/cleanhtml.py I use it to strip out all the html leaving a nice plain string. It does the best job of any solutions I've seen. TJ I think he just wants to make sure the HTML is well-formed, not strip the tags completely. However, strip_tags() is something WebHelpers should provide. I've noticed the lack a couple times. However, I'm not sure of the best implementation. strip_tags should be easy enough to implement with some regexes -- you just have to remove .*?, then resolve any entities. This code does some fairly simplistic rendering of HTML (but better than what strip_tags would likely do), and might have a better home in WebHelpers: http://svn.w4py.org/ZPTKit/trunk/ZPTKit/htmlrender.py -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: How did you begin your fun with Pylons?
Sphinx looks likely to become it. Both Pylons and Paste have switched to it, as has Python's development versions. See: http://docs.pylonshq.com/ (unfinished) http://pythonpaste.org/ These are basically unfinished too, but I figured it was better than how it used to be anyway. http://docs.python.org/dev/ (Python 2.6a3) http://docs.python.org/dev/3.0/ (Python 3) I haven't used Sphinx myself but I believe it combines ReStructured Text articles into a book, and you can stick docstring-generated content wherever you want. Ben has some plan to import the documentation from Pylons' component projects into this scheme, but I'm not sure exactly how it works. I imagine it's something like svn:external for Sphinx content and a downloader-converter for non-Sphinx content. You just tell Sphinx to put an object's docstring in a particular location, and it does it. So as long as the other packages are installed you can insert their docstrings in. Pylons is doing this out of necessity because we need the documentation. The Pylons docs themselves could theoretically be a building block for some other documentation, but nobody has yet outlined what that documentation might be. Perhaps a central documentation repository in PyPI, or all web-related documentation at docs.pythonweb.org. There has been some discussion about a closer relationship between these projects (mostly Pylons, Paste, TG, and Repoze), and having a cohesive documentation story is a big part of that. We don't have any actual plans yet, though, just intentions. A perennial problem with documentation is that building its structure or tools takes time away from writing the content. That's why Pylons went with Confluence originally for its wiki, because Confluence provided a quick way to start writing without having to build infrastructure). I find Sphinx fairly workable. At least personally I really prefer to write docs in text files under version control, which is what Sphinx is built for. I think Sphinx's emphasis on hand-crafted documentation is probably best. Python for years used LaTeX with custom stylesheets. Other projects like Cheetah followed suit. But LaTeX is a pain to maintain compared to the newer HTML/DocBook/XML and ReST formats. But ReST didn't support multi-article books very well (i.e., no standard way to make next/previous/up links at the bottom of the page). Various programs were written to fill this gap, but none emerged as pre-eminent so it was a mess. Pylons started using Pudge as a structure for application documentation, but Pudge was difficult to install and buggy. Then Sphinx came along and does it all better. I don't know how well it handles multilingual docs; maybe somebody else can answer that. I don't think it has any special support. I'm not sure what that support would look like, but it's under active development and if someone can suggest something it might happen. People have implemented automatic Google translation links, and I guess they are okay at being readable, though no one was able to figure out a way to protect the code samples from translation. It would be spiffy if we could do automatic translation with hints when the translation goes wrong, so as to reduce the translation overhead. E.g., I could imagine a custom translation dictionary as ambiguous words are probably not very ambiguous in the context of our documentation (e.g., code almost always means source code not cipher). I don't know if there's translation services with a complete enough API for that sort of thing...? The public translation services seem pretty much all-or-nothing. But maybe translation with fixup? E.g., translate everything, then re-insert code samples over the translated code samples. And find phrases that are wrong and do a search-and-replace on those phrases. If you save the search-and-replace commands (as submitted by readers/translators) instead of saving the resulting text, they could be reapplied to the documentation after it is rebuilt, when the upstream documentation has changed. Obviously not perfect, but seems a whole lot easier to maintain than other translation strategies. Especially when completeness and accuracy is more important than expressiveness -- if you aren't sure the translated docs are completely right and complete, you'd be well served to read the original docs even if that's harder for you to do. (I think this is where translation of programming documentation is probably different than many other typical translation situations, where you might be more reluctant to deal with an obviously inferior automatically translated document.) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email
Re: Application keeps 'stalling'
What server are you using? Jonathan Vanasco wrote: An application i have running keeps randomly quitting or stalling. Quitting- I'm tracing a ton of stuff, I can't seem to figure out why its dying. I'm hoping monit can at least restart the next time. Stalling- Ive been running ab to bench and test it, hoping to find the quit. Running ab -n 1 -c 10 http://site.com/contact; I will always get this message around 4220 requests if i go through nginx , 8440 requests if i hit paster directly ( +- 3 requests over 30 tests -- very weird. i've never seen a bunching of results like this before ) apr_poll: The timeout specified has expired (70007) The site will be frozen for a minute or so, then be responsive again. Looking at the paster logs, no issues exist. Looking at pg_stat activity, there's no transaction - we're idle. anyone have a clue? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: paste.registry as a standalone EGG
Alberto Valverde wrote: Hi, Are there any plans to pull paste.registry out of the Paste distribution into a separate one? There aren't, mostly because the registry has always made me a little uncomfortable. Usually when separating things out, I like to review the code and have a certain sense that the code is as simple and understandable as it can be. I don't feel like paste.registry is at that point, though of course I would like it to be. I'm not exactly sure what would make it simpler. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Calling a WSGI application from an action
Alex Marandon wrote: 2008/5/30 Ian Bicking [EMAIL PROTECTED]: I'm trying to apply the recipe from http://wiki.pylonshq.com/display/pylonsdocs/Web+Server+Gateway+Interface+Support#running-a-wsgi-application-from-within-a-controller Unfortunately it works only for the file management features, not for the upload. After digging into FCKeditor's Python code I figured out that the WSGI app doesn't get all the data it needs from from the WSGI environment. I dumped the WSGI environment when running the app under mod_wsgi directly and within Pylons and there happen to be a lot of differences between the two. I'm wondering if there would be a way to get access to the original WSGI environment, before it gets modified by Pylons, so that it would be compatible with what a regular WSGI application expect. WebOb makes this easier, with: resp = req.get_response(fckeditor_wsgi) If you aren't using a very new version of Pylons, you can make a webob request with webob.Request(request.environ) However, there is a problem that the POST body can be eaten up. WebOb specifically tries to reconstruct it, but not for file uploads (simply because I didn't get around to it, because it's harder to construct than a simple POST form). And maybe what you are encountering is this same issue. Hi Ian, thanks a lot for answering my message. One thing I don't understand, is why the POST body gets deconstructed in the first place. I don't have a deep understanding of WSGI yet, but I thought one of its advantages was to allow developers to build arbitrary chains of middlewares and applications that are not aware of each others. So how come Pylons is modifying the POST body in such a way that it can't be used by subsequent WSGI component in the chain? Generally yes, but this specifically is a problem. If you don't access request.POST (or request.params) it won't read the body, but it's possible something in Pylons accesses one of these early on. This recipe roughly describes what a file upload looks like: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146306 You need code that takes req.POST and turns it into the serialized body, so that the WSGI app you are calling can reconstruct that body. I understand that Pylons parses the body of the POST request and turns into a Python data structure. In particular, any uploaded file gets turned into a cgi.FieldStorage. What I need to do is convert it back to its serialized version. Am I correct so far? Then where should I set the serialized version so that it can be used by oher WSGI apps? It seems that request.POST can't be assigned a new value. You'd put a new file-like object into wsgi.input, like: from cStringIO import StringIO environ['wsgi.input'] = StringIO(serialized_body) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Calling a WSGI application from an action
Alex Marandon wrote: Hello, I'm trying to integrate FCKeditor's file management and upload features into a Pylons app. FCKeditor ships with a WSGI application to handle the server side of these features. That's cool, that's one of the first cases I've heard of a Javascript product shipping something in WSGI (usually it's just PHP). I tried to run that application under mod_wsgi and it works fine. Now I'd like to integrate that within my Pylons app to take advantage of my authentication mechanism, so that only registered users can upload files. I'm trying to apply the recipe from http://wiki.pylonshq.com/display/pylonsdocs/Web+Server+Gateway+Interface+Support#running-a-wsgi-application-from-within-a-controller Unfortunately it works only for the file management features, not for the upload. After digging into FCKeditor's Python code I figured out that the WSGI app doesn't get all the data it needs from from the WSGI environment. I dumped the WSGI environment when running the app under mod_wsgi directly and within Pylons and there happen to be a lot of differences between the two. I'm wondering if there would be a way to get access to the original WSGI environment, before it gets modified by Pylons, so that it would be compatible with what a regular WSGI application expect. WebOb makes this easier, with: resp = req.get_response(fckeditor_wsgi) If you aren't using a very new version of Pylons, you can make a webob request with webob.Request(request.environ) However, there is a problem that the POST body can be eaten up. WebOb specifically tries to reconstruct it, but not for file uploads (simply because I didn't get around to it, because it's harder to construct than a simple POST form). And maybe what you are encountering is this same issue. This recipe roughly describes what a file upload looks like: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/146306 You need code that takes req.POST and turns it into the serialized body, so that the WSGI app you are calling can reconstruct that body. I'd be happy for webob to be able to do this, if you are inclined to add it there -- the code is in webob.FakeCGIBody._get_body(), and the instance would have to be aware of the Content-Type of the upload, and if it's multipart/form-data then it would have to reconstruct the body differently, in line with what that recipe does. Another minor issue I've got is that the HTTP Content-Type header (text/xml in this case) is not sent properly when calling the WSGI app from Pylons. That one is not very critical as I can set it with the controller action which calls the WSGI app. I can't think of anything that would change that header; maybe it wasn't set properly on the request to start with? -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: advice with configuration/scaling a live Pylons app.
Paweł Stradomski wrote: W liście SamDonaldson z dnia czwartek 29 maja 2008: Yes, lighttpd serving static and all dynamic requests forwarded to the paster process talking SCGI. Should I make the switch to nginx as it seems like everybody has something good to say about nginx, and it's a good load balancer. Also, is the fact that I'm only running a single paster process a problem? I remember iwth RoR, mongrel started multiple child processes. RoR is non-threadsafe and uses processes to allow concurrent access. Pylons, on the other hand, uses threads. I don't know if starting multiple processes would give much. The default server(s) (Paste's and CherryPy's both) use threads, but Pylons is not particularly tied to threads. Multiple processes can definitely speed up your application on multi-processor/multi-core systems. And setups like that shouldn't really hurt on other systems. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Deleting PATH_INFO in WSGI 2
Graham Dumpleton wrote: Mike Orr wrote: On Wed, Apr 30, 2008 at 6:21 AM, Ian Bicking [EMAIL PROTECTED] wrote: Yannick Gingras wrote: Ian Bicking [EMAIL PROTECTED] writes: For this particular problem, I can work around the slashes collapsing with a regexp but it would indeed be nice to have a general workaround in WSGI 2. Where is it discussed? Discussion happens on the Web-SIG mailing list, though there hasn't been any discussion lately. There's also the wiki page: http://wsgi.org/wsgi/WSGI_2.0 On the page it says SCRIPT_NAME, PATH_INFO, and QUERY_STRING are recommended for removal. How would url_for() be able to recreate the URL without them? More to the point, how could Routes or Pylons work at all without PATH_INFO: you wouldn't know which controller to route to. And REMOTE_ADDR and SERVER_SOFTWARE: the application may want REMOTE_ADDR for authentication or logging, and SERVER_SOFTWARE is theoretically useful if the app wants to modify its behavior according to the server. Hmmm, I wander if the page is just badly worded. Maybe they meant that 'optional' designation be removed, thereby making them mandatory. That's correct; I fixed the language. Making the keys required and removing them altogether are very different -- I simply wanted them to be required. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: fd limit
Anil wrote: Is it possible with paster (through .ini files?) to set the max file descriptors available to it? I guess otherwise I'll have to write a wrapper script and do a ulimit. It doesn't, and I'm not sure you actually can from inside the process. My vague recollection is that you really need to do that from a wrapper script. Even if you can, I'm not sure where it'd go in the config file, so I'd still suggest just sticking with a wrapper. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: deploying webob without long running processes?
iain duncan wrote: I'm not sure where to ask this so sorry if it's OT. I know pylons is (optionall?) moving to WebOb, and I'd like to get more experience using it. I frequently find myself writing mini-apps for clients that need to be hosted in a crappy environment but really don't need to execute fast. Are there any examples around of how you might use webob in a cgi deployment scenario? Is this possible? There's a CGI runner in the wsgiref package. App Engine basically uses CGI, and the file for launching a Pylons/Paste-Deploy app with it basically will work elsewhere too: https://appengine-monkey.googlecode.com/svn/trunk/paste-deploy.py -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: unicode bug?
There's a good chance this is fixed in FormEncode trunk. Try
easy_install FormEncode==dev
[EMAIL PROTECTED] wrote:
Hi,
I am using pylons with formencode and international setting set to
'cs':
formencode.api.set_stdtranslation(domain=FormEncode,
languages=['cs'])
However, I don't know if it's a problem between the keyboard and
chair, I have encountered a few UnicodeErrors. For example I have an
login form where I am simply controlling the length of login:
# a draft
class UserController(BaseController):
def login(self):
if not len(request.params):
return render('/user-login.mako')
try:
form_result =
form.LoginSchema().to_python(request.params)
except formencode.Invalid, e:
defaults = request.params
errors = e.error_dict
return formencode.htmlfill.render(render('/user-
login.mako'), defaults, errors, encoding='utf-8')
else:
return 'yupi'
when I call it with not set variables, it should display a
nationalized response type a value, but instead I get an
UnicodeError exception in formencode/htmlfill.py:110:
return cgi.escape(str(v), 1)
exceptions.UnicodeEncodeError: 'ascii' codec can't encode character
u'\xed' in position 4: ordinal not in range(128)
I am doing something wrong?
I found 2 hacks to resolve it:
1) patch htmlfill.py, replace line 110 with this:
return cgi.escape(unicode(v), 1)
or (for those who are forced to use standard or old packages)
2) create a function and preprocess e.error_dict:
def fix_bug(exceptions):
ret = exceptions
for k in ret.keys():
ret[k].args = unicode(exceptions[k].args).encode('utf-8')
ret[k].msg = unicode(exceptions[k].msg).encode('utf-8')
ret[k].value = unicode(exceptions[k].value).encode('utf-8')
return ret
errors = fix_bug(e.error_dict)
Any thoughts?
Karol
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: unicode bug?
Karol Tarcak wrote: rewritingparser.py - html_quote looks identical + it has the same comment to use unicode :) def html_quote(v): if v is None: return '' elif hasattr(v, '__html__'): return v.__html__() elif isinstance(v, basestring): return cgi.escape(v, 1) else: # @@: Should this be unicode(v) or str(v)? return cgi.escape(str(v), 1) Ah, there was a different problem I fixed related to unicode. I've switched this in trunk to use unicode() when a __unicode__ method is present. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: sys.path
Karol Tarcak wrote: Hi, I have to run my app in a quite restrictive environment (no eggs, only standard packages from debian stable, no shell), I am going to use some additional modules (for example authkit) ... I would like to change the import path on my app startup to add an extra directory where all additional modules will be stored ... Any thoughts? You might want to do something similar to appengine-monkey: https://appengine-monkey.googlecode.com/svn/trunk/paste-deploy.py (it uses a virtualenv and then also a fixup script to make the virtualenv somewhat relocatable: https://appengine-monkey.googlecode.com/svn/trunk/pth_relpath_fixup.py) -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: sys.path
Mike Orr wrote: On Wed, May 14, 2008 at 8:58 AM, Ian Bicking [EMAIL PROTECTED] wrote: You might want to do something similar to appengine-monkey: https://appengine-monkey.googlecode.com/svn/trunk/paste-deploy.py (it uses a virtualenv and then also a fixup script to make the virtualenv somewhat relocatable: https://appengine-monkey.googlecode.com/svn/trunk/pth_relpath_fixup.py) Those pages require authentication. Oops, they are from my checkout. Take of the https and it should be okay. What are the current limitations for making virtualenvs relocatable? Well, the activate script is hardcoded, and possibly some python setup.py develop locations, and the location of the standard prefix. The only one that matters in a deployed situation is python setup.py develop locations (which pth_relpath_fixup fixes). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: sys.path
[EMAIL PROTECTED] wrote: Hi all, is there a possibility to modify sys.path each time a request is processed (i.e. just before pylons is started)? You could, but it probably won't work like you want. If a module is already loaded it will not be reloaded, despite changes to sys.path. I'm not sure what you are trying to do, but maybe something like exec will work better (i.e., something that doesn't use the import machinery at all). -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Running Pylons with PHP
Damian wrote: This is a really interesting module - does anyone know what sort of overheads it has? I can see this as being quite useful for migrating legacy php code to a pylons app allowing you to reuse some existing php code in an updated pylons app, either for transitioning it or using a mix of the two that integrates cleanly. We don't use it in production, but instead have a complete Apache instance to run a PHP app (WordPress) and use WSGI-based HTTP proxying from Python. But the basic effect is the same, wphp just uses FastCGI proxying instead of HTTP. The overhead hasn't seemed that substantial, though passing static files through Python can add some unnecessary overhead, including stuff like taking up one of a limited number of worker threads. The actual overhead of running the PHP scripts (especially something complex) will usually be much more than the proxying overhead. Incidentally, there's also a similar setup for running CGI scripts, which you can use to run, for example, Mailman. You get all the normal CGI overhead in this case, but again that's probably less than the overhead of a Python intermediary. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
