On 2011-04-04 11:31:15 -0700, Chris McDonough said:
I think "researchy" describes some of the marrow stuff pretty well
(that doesn't imply bad, unusable or unstable, it just implies
opinionatedness that is outside the current mainstream). For example,
in this message you've quoted use of a futures-based asynchronous
server that says it implements WSGI 2.0, but WSGI 2.0 does not yet
exist in any ratified form. I don't see WSGI 2.0 draft compatibility
as a goal that we need to explore under GSOC. I think it's great
you're pushing the envelope, but we really just need some very simple
things that are well behind any of the curves you're at the front of.
I agree with regards to m.s.http; it was originally developed as a
'proof of concept' server to be developed in parallel with my rewritten
PEP 444. However, making it speak PEP 333(3) is relatively trivial.
At the grossest level (callable syntax), you use the following p-code
decorator:
def make_pep444(fn):
def inner(environ):
def start(status, headers):
start.status = status
start.headers = headers
body = fn(environ, start)
return start.status, start.headers, body
return inner
In the meantime, I don't much care if we get a PasteDeploy replacement
that works under Python 3.X for GSOC. Pyramid apps don't strictly
require PasteDeploy, they can be run without any declarative
configuration. I also don't care much if we don't get a PasteScript
replacement for GSOC either. Having a command line wrapper that does a
bunch of stuff is handy but not required to make things run.
They remain nice goals, however +1 on pairing down to the minimum.
— Alice.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
