[Async-sig] SansIO (Was: PEP: asynchronous generators)

[Cory Benfield]

> On 8 Aug 2016, at 07:56, Yarko Tymciurak <yarkot1 at gmail.com> wrote:
> 
> Question: isn't SansIO / Corey's work just a specific instance of Bob Martin's "Clean Architecture"?  It sounds familiar to me, when thinking of Brandon Rhode's 2014 PyOhio talk, and his recast of the topic in Warsaw in 2015.  It seems like it...  If so, then perhaps async aspects are just a second aspect.


Yeah, so this is worth highlighting more clearly. =) I apologise to the list in advance for this, but this is going to be something of a digression, so I have re-titled the thread.

I have invented and pioneered *nothing* here. Designing protocol implementations this way is not new in the world of software development. No-one is going to give me a medal or name a design pattern after me, and I don’t even think that pushing for this design pattern will help me move up my employer’s technical career path the way spending time on writing RFCs would have.

However, I think we can safely say that the Python community has not effectively done this over our twenty-plus year lifetime. Brett’s “sans-io” page is a beautiful example of this: currently we can find maybe *three* libraries that tick the box of being I/O-independent. This, in my mind, points to a cultural problem in the Python community. For whatever reason, we have tricked ourselves into abandoning what I would call “good software design”.

I have my theories for why this is. A huge factor of this is the relative ease-of-use of sockets and other I/O tools in Python (relative to C, that is: languages that also have this relative ease of use have similar problems, such as Javascript and Ruby). Another factor is the Python community’s love of beautiful APIs. Libraries with beautiful APIs provide such an appeal to programmers that there is huge incentive to build such a library. Building such a library requires including your I/O, and in the absence of any I/O-free implementations of a protocol you are almost certainly going to take the path of least resistance, which means intermingling your I/O and event loop primitives with your protocol code.

And I’m not criticising programmers that do this. As I pointed out with the fake title of my talk, I am a programmer that does this! Almost all the best programmers our community has to offer have done this and continue to do this. It really is easier. And trust me, as someone who has written one: there is very little that is sexy about writing a protocol library that does no I/O. It doesn’t make you famous, and it doesn’t make anyone applaud your design sense. They’re extremely boring and prosaic, and they rarely solve the actual problem you have: they are a step on the road to solving the problem generally, but not specifically.

So am I talking about the same thing as Brandon? Yes, yes I am. And Brandon is a better speaker than I am, so I agree that it’s weird that I’m getting more credit for this than he is. But I suspect that I’ve had some advantages that Brandon didn’t have.

The first is that, by sheer good luck, I’ve managed to tap into a zeitgeist and be in the right time at the right place to deliver this message. Dave Beazley’s work on curio here is helping, because of curio’s sheer incompatibility with the other event loop approaches, which means that his work and mine have a nice symbiosis. Nathaniel and I have managed to give him the building blocks to demonstrate curio’s effectiveness without him needing to be an expert in HTTP.

The second is that, I think, Brandon was targeting a different audience. Brandon was trying to talk to the general case, but he stopped short of the case I made. If you go back to watch Brandon’s talk, he talks about hoisting your I/O to the top of your control flow, but never leaps forward to say “and this has a very specific application to any tool or library that talks a network protocol”. My argument is actually *more specific* than Brandon’s: I am saying that you can strip out the low-level stuff into an entirely separate logical codebase, and then not just change the *type* of I/O you do, but change the complete style in which you do it. Brandon’s argument isn’t so much about code reuse as it is about code maintenance.

That said, I think the real reason people are talking about my work and not Brandon’s is because, while we both said “You should hoist your I/O out of your logic”, I got to follow up with “and I have done it and released the code and it’s actually being used today in projects you know about”. That second argument really does help, because whenever you tell people to totally change the way they’re writing something, they have a tendency to go “Oh, yeah, but that doesn’t work for *my* project”. Being able to say “look, I did it, it really does work, and here are all the ways that it let me build a better thing”.

That said, I’d love to have Brandon weigh in on this too. I do feel a bit bad that I am re-treading ground that others have covered before, but…hell, we can’t all be top-tier programmers! If all I say is that I have repackaged an idea my intellectual betters have previously made such that it’s more appealing to the masses, I think I can call myself happy with that.

Cory


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160808/7f57f230/attachment-0001.html>