search

lvh / async-pep

Draft PEP for asynchronous IO
ISC License
62 stars 7 forks source link

Trivial implementation of the async PEP backend #22

Open lvh opened 13 years ago

lvh commented 13 years ago

This actually belongs in the async module because it should eventually go into the stdlib as the lowest common denominator implementation.

It should be able to run the protocol described in #21.

jerub commented 13 years ago

22:04 < Jerub> exarkun: it's an idea that was discussed, including a mainloop implementation that supports async-pep style protocols in stdlib. 22:04 < Jerub> i don't know if it's worth doing, i'd appreciate input 22:06 < exarkun> There should be a way for people to use protocols that follow the pep using just the standard library. 22:07 < Jerub> yeah, okay, that's what our reasoning was. 22:07 < exarkun> The equivalent of wsgiref 22:07 < Jerub> one idea was to do it using asyncore, another was to just implement it with poll/select or something. 22:07 < exarkun> It should probably be based on asyncore 22:07 < Jerub> probably end up being a cut+paste from pollreactor or selectreactor or something if we didnt' use asyncore.

fmayer commented 13 years ago

I'm -1 on asyncore.

hynek commented 13 years ago

I wonder about the implications. Using asyncore sounds like technical debt.

Is it to be expected that we'd have to rewrite it several times anyway before being merged? Then it might be a good idea to go the fastest way.

Otherwise a self-contained, clean implementation from the beginning on sounds more appealing to me.