[Python-ideas] asyncore: included batteries don't fit

Laurens Van Houtven _ at lvh.cc
Thu Oct 18 13:01:30 CEST 2012


Do you use gevent's monkeypatch-the-stdlib feature?

On Tue, Oct 16, 2012 at 8:40 PM, Matthias Urlichs <matthias at urlichs.de>wrote:

> I'll have to put in my ..02€ here …
>
> Guido van Rossum <guido at ...> writes:
>
> > (2) We're at a fork in the road here. On the one hand, we could choose
> > to deeply integrate greenlets/gevents into the standard library.
>
> Yes.
>
> I have two and a half reasons for this.
>
> (½) Ultimately I think that switching stacks around is always going to be
> faster
> than unwinding and re-winding things with yield().
>

That seems like something that can be factually proven or counterproven.


> (1) It's a whole lot easier to debug a problem with gevent than with
> anything
> which uses yield / Deferreds / asyncore / whatever. With gevent, you get a
> standard stack trace. With anything else, the "where did this call come
> from"
> information is not part of the call chain and thus is either unavailable,
> or
> will have to be carried around preemptively (with associated overhead).
>

gevent uses stack slicing, which IIUC is pretty expensive. Why is it not
subject to the performance overhead you mention?

Can you give an example of such a crappy stack trace in twisted? I develop
in it all day, and get pretty decent stack traces. The closest thing I have
to a crappy stack trace is when doing functional tests with an RPC API --
obviously on the client side all I'm going to see is a fairly crappy
just-an-exception. That's okay, I also get the server side exception that
looks like a plain old Python traceback to me and tells me exactly where
the problem is from.



> (2) Nothing against Twisted or any other async frameworks, but writing any
> nontrivial program in it requires warping my brain into something that's
> *not*
> second nature in Python, and never going to be.
>

Which ones are you thinking about other than twisted? It seems that the
issue you are describing is one of semantics, not so much of whether or not
it actually does things asynchronously under the hood, as e.g gevent does
too.


> Python is not Javascript; if you want to use the "loads of callbacks"
> programming style, use node.js.
>

None of the solutions on the table have node.js-style "loads of callbacks".
Everything has some way of structuring them. It's either implicit switches
(as in "can happen in the caller"), explicit switches (as in yield/yield
from) or something like deferreds, some options having both of the latter.


> Personal experience: I have written an interpreter for an asynchronous and
> vaguely Pythonic language which I use for home automation, my lawn
> sprinkers,
> and related stuff (which I should probably release in some form). The code
> was
> previously based on Twisted and was impossible to debug. It now uses
> gevent and
> Just Works.
>

If you have undebuggable code samples from that I'd love to take a look.


>
> --
> -- Matthias Urlichs
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
cheers
lvh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121018/cb7923b6/attachment.html>


More information about the Python-ideas mailing list