Re: Async support refactoring

On Sat, Apr 24, 2010 at 5:28 PM, Manlio Perillo
<[email protected]> wrote:

>> It is probably good for twisted people
>> because they are used to do everything their way, but there is a lot
>> of people who may want to deploy Django using a even-driven wsgi web
>> server, or use SQLAlchemy, or have a program already written and want
>> to move from threads to greenlets (which is what happened to a project
>> of ours: psycopg is currently the only piece of the puzzle that still
>> forces us to use a thread and stops us to try the promising gevent).
>>
>
> But this can be done by implementing greenlet support in a pure Python
> wrapper.
>
> As an example, you can write a custom dialect for SQLAlchemy, or a
> custom plugin for Django.
>
> You don't need to have direct support inside psycopg.

[...]

> My point is that you are adding a feature not strictly required in a C
> extension module (and that needs to be maintained), and that will not
> work with all kind of applications.

So: a python wrapper for coroutines around the async api, rebuilding
sessions, named cursor etc in python instead of C. On top of it, a
customized Django or a customized SQLAlchemy or a customized version
of everything already working... Isn't this some code needing
maintenance?

There is a small number n of coroutine-based framework, and a fairly
large number m of libraries that may be used in a coroutine-based
project. In order for psycopg to be useful in this context, m projects
should be modified in order to use the async flavour of psycopg. The
wait callback allows to have all the m already working, through a
dependency injection, and doesn't even need the n frameworks to be
modified: only a straightforward function to be written for each of
them. I fail to understand what do you mean for maintainability.

-- Daniele