On Jan 3, 2005, at 6:25 AM, Oleg Broytmann wrote:
>
>    Seems like another task for a decorator.
>
> def published(func):
>    def wrapper():
>       request = get_request()
>       func(request)
>    return wrapper
>
> @published
> def myfunc(request):
>    process(request)
>
> (This is only a very rough draft, of course.)
>

I don't think this really gets you there.  Yes, it does get you a
request parameter, but that's not really the point, and, it doesn't
help with get_session, get_response, get_field, etc.  The point is to
increase the modularity, reentrancy, innate goodness ;--), etc. of my
code.

The current implementation restricts you to a single publisher per
process, and relies on that fact.  It makes it more difficult to
implement different processing models - multiple simultaneous requests
per thread, chaining one request across multiple threads, etc.  For
example, I don't know much about Twisted, but I do know it's based on
async IO, which means you can probably have multiple outstanding
requests on the event processing thread.  How hard would it be to write
an adapter to let you use Quixote 2 in that environment and not require
a full return into Quixote on every request?  (I really don't know -
it's not just a rhetorical question).

It also makes it difficult to serve multiple sites out of a single
process.  Even if you use your own implementation of Publisher to get
around this, the global-ish interface will make your life more
difficult, especially if you want to plug in other people's code.
Looking at the 2.0a3 implementation of Publisher, it looks like that
limitation exists solely to enable get_request() and friends.  IMHO,
it's not a good tradeoff.

Please don't take this as Q-bashing.  I really like the Quixote way of
structuring a web app, and I think the introduction of Directory was a
great idea.  I'm just pointing out something that I think is going to
cause difficulty in the long run.

--
Zac