> On Nov 23, 2014, at 9:24 PM, Donald Stufft <don...@stufft.io> wrote: > > > There’s a long history of implicit context switches causing buggy software > that breaks. As far as I can tell the only downsides to explicit context > switches that don’t stem from an inferior interpreter seem to be “some > particular API in my head isn’t as easy with it” and “I have to type more > letters”. The first one I’d just say that constraints make the system and > that there are lots of APIs which aren’t really possible or easy in Python > because of one design decision or another. For the second one I’d say that > Python isn’t a language which attempts to make code shorter, just easier to > understand what is going to happen when. > > Throwing out hyperboles like “mathematically proven” isn’t a particular > valuable statement. It is *easier* to reason about what’s going to happen > with explicit context switches. Maybe you’re a better programmer than I am > and you’re able to keep in your head every place that might do an implicit > context switch in an implicit setup and you can look at a function and go “ah > yup, things are going to switch here and here”. I certainly can’t. I like my > software to maximize the ability to locally reason about a particular chunk > of code.
But this is a false choice. There is a third way. It is, use explicit async for those parts of an application where it is appropriate; when dealing with message queues and things where jobs and messages are sent off for any amount of time to come back at some indeterminate point later, all of us would absolutely benefit from an explicit model w/ coroutines. If I was trying to write code that had to send off messages and then had to wait, but still has many more messages to send off, so that without async I’d need to be writing thread pools and all that, absolutely, async is a great programming model. But when the code digs into functions that are oriented around business logic, functions that within themselves are doing nothing concurrency-wise against anything else within them, and merely need to run step 1, 2, and 3, that don’t deal with messaging and instead talk to a single relational database connection, where explicit async would mean that a single business logic method would need to be exploded with literally many dozens of yields in it (with a real async DBAPI; every connection, every execute, every cursor close, every transaction start, every transaction end, etc.), it is completely cumbersome and unnecessary. These methods should run in an implicit async context. To that degree, the resistance that explicit async advocates have to the concept that both approaches should be switchable, and that one may be more appropriate than the other in difference cases, remains confusing to me. We from the threading camp are asked to accept that *all* of our programming models must change completely, but our suggestion that both models be integrated is met with, “well that’s wrong, because in my experience (doing this specific kind of programming), your model *never* works”. > > --- > Donald Stufft > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
