David Shi wrote:
I have a Python script that automatically downloads zip files containing
large datasets from another server and then unzips the files to further
process the data.
This smells more like it belongs on comp.lang.python that wb-sig, but
here goes...
The script works fine when
Hey Jim,
Jim Fulton wrote:
Bobo is a light-weight framework for creating WSGI web applications.
Do you know if there are plans/possibilities to make the routing part of
Bobo available for other frameworks and/or in a non-decorator fashion?
cheers,
Chris
--
Simplistix - Content
Fred Drake wrote:
I'd be in favor of keeping only HTMLParser, with a compliant module
name (htmlparser doesn't seem unreasonable). The code was
originally derived from htmllib for the Grail webbrowser, mostly to
make things like attribute handling less painful.
Really? Cool. My first
Luis Bruno wrote:
Chris Withers escreveu:
Adam Atlas wrote:
http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py
What's the egg it's distributed in?
I normally use egg:PasteScript#cherrypy
I'm afraid I have no idea what this means... can you explain?
cheers
Hi All,
The subject line kindof says it all, but is there a wsgiref for python 2.4?
Failing that, what's the lightest-weight wesgi server available for
python 2.4?
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
Adam Atlas wrote:
http://pypi.python.org/pypi/wsgiref
It wouldn't hurt to look at CherryPy's WSGIServer anyway. I think it's
generally a lot more efficient/scalable than the BaseHTTPServer-based
implementation in wsgiref, and it's reasonably lightweight (one .py
file, 1311 lines).
Manlio Perillo wrote:
The interface of the python logging is:
log(level, msg[, *args[, **kwargs]])
right?
The problem with this is that, as an example, Twisted logging system
does not knows about log levels.
Moreover, the message formatting is not done by the logging system.
Then,
Manlio Perillo wrote:
I don't really see how this helps. If it's optional, then ever wsgi
app will need a bunch of if/then/else to decide if this method can be
called and what to do instead.
This is not a problem. The job can be done by a middleware.
...which everyone will then have to
Manlio Perillo wrote:
wsgi.errors maybe should have an optional method:
.msg(level, *args)
where args is a list of strings
or
.msg(*args, **kwargs)
where the keys in kwargs are implementation defined.
I don't really see how this helps. If it's optional, then ever wsgi app
will need
Phillip J. Eby wrote:
Why would they need to? The logging module has its own registry of
loggers.
getLogger('x.y.z') only creates a logger if it doesn't already exist...
You're only shifting the issue from taking loggers as arguments, to
logger *names* as arguments.
Huh? How so? Just
Phillip J. Eby wrote:
At 02:03 PM 12/21/2007 +, Chris Withers wrote:
I think I'm missing something: what in the logging package makes you
log by which module issued the message?
That's the conventional usage: modules that use logging usually use a
static logger based on module name
Brian Smith wrote:
It would make more sense for the WSGI specification to explicitly say
that WSGI gateways are responsible for setting the default logging
output location.
Yes, although by this I assume you mean WSGI gateways are responsible
for allowing configuration of log handlers for the
Graham Dumpleton wrote:
At least in the context of Apache, wsgi.errors is different to
sys.stderr or a global logging module output target. This is because
wsgi.errors is linked to the actual request and so any output can be
correctly redirected to a per virtual host error log.
Yeah, but
Phillip J. Eby wrote:
There are other logging systems out there besides the Python logging
module -- and some of them are better for their specific
purposes.
Can you give some examples?
And the Python logging module doesn't give you any
WSGI-level control over output.
What do you
Manlio Perillo wrote:
For me, it does feel like the responsibility of the server to
configure logging, and I think this is something that should be
documented somewhere. Afterall, as you guys have been discussing, it's
the server that holds configuration for things like listening sockets,
Graham Dumpleton wrote:
Where does setting up 'logging' module configuration fall in all of
this and who/what should handle it?
Indeed, this is definitely something I've wondered myself...
paster, when loading an application via the paster serve, shell or
setup-app commands, calls the
Manlio Perillo wrote:
2) handle the range request in the WSGI application.
Its not hard as long as you do not implement multiple ranges support.
If your object database supports seeks, this should be the most
efficient solution.
This is probably what's wanted. So, if a wsgi app
Ionel Maries Cristian wrote:
wsgi.file_wrapper doesn't support sending a file from a specific offset as
per wsgi spec.
what are your thoughts on this ?
This was one of the things I was asking about when enquiring about
wsgi's support for large files previously.
Zope's
Graham Dumpleton wrote:
package. You can if appropriate even use a combination of both modes.
So these would just be seperate sections in apache's config files?
For example, run Django in embedded mode for best performance,
Why does this give best performance?
but
delegate a Trac instance
Graham Dumpleton wrote:
For daemon mode, in mod_wsgi 2.0 there is also 'Process' reload
mechanism as an option. Just touching the main WSGI script file entry
point will cause just the processes for that daemon process group to
be restarted on next request, thereby avoiding a restart of the
Tres Seaver wrote:
Note first that we use mod_wsgi's daemon-mode exclusively,
Forgive me for being uninformed, but what are the other options?
which
implies creating one or more dedicated subprocesses for each process
group defined in the Apache config.
Does each sub process get its own
Ian Bicking wrote:
At least in Pylons apps, configuration is setup during instantiation.
Configuration is generally copyable (consisting of stuff like strings,
not open file objects), so it can be cloned across processes easily.
I can understand sharing across threads, but how do you share
Robert Brewer wrote:
In a multithreaded environment, I recommend apps read config only at
process startup, parse the entries and use them to modify live objects,
and then throw away the config. Then, if you need to make changes to
settings while live, you just modify the live objects in the
Graham Dumpleton wrote:
As for general issues around best way to perform application
initialisation, problem is that what is the most appropriate way may
depend on the specific hosting mechanism. There isn't necessarily
going to be one way that will suit all ways that WSGI can be hosted,
thus
Hey All,
I hope I have the right list, if not please point me in the right
direction...
Likewise, if there are good docs that cover all of this, please send me
their way ;-)
Right, I'm curious as to how wsgi applications end up being
multi-threaded or multi-process and if they are, how they
DiPierro, Massimo wrote:
here are some unique features:
1) full web based development, deployment and management of applications, no
more shell commands (unless you want them)
Good. Zope seems to have moved away from this, which is a shame...
2) built-in ticketing system to report bugs to
Jim Fulton wrote:
It all gives indication. Yes, if only one person says this sucks,
then their opinion may not be worth changing the implementation for.
However, if 50% of users said this sucks, even if they couldn't
explain why, that'd be something worth worrying about.
Sure, but how
Jim Fulton wrote:
I do a lot of unix deployment, and the thought of a buildout that
sprays files all over the system, even if they are in standard unix-y
location scares me a lot...
That's because you are a developer.
OK, I see what you mean now, although I think it's clear that
Rodrigo Senra wrote:
For symmetry's sake in Windows a Python service manager could simply
use SCManager API under the hood (through win32all) to get the job done,
still keeping a consistent cross-platform modus operandi.
I would love to see this, particularly for Zope, although I sadly don't
Jim Fulton wrote:
On Mar 5, 2007, at 4:38 PM, Phillip J. Eby wrote:
...
Personally, I don't care for the Paste Deploy syntax -- frankly
it's almost barbaric. :)
I don't mean to pick on you, but I really *hate* comments like this.
That's okay ;-)
criticism. I'd appreciate it if we
30 matches
Mail list logo
