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

[Guido van Rossum]

OK, never mind Impostor Syndrome... How can we move this forward in
the community though actual applications? Should we have the complete
I/O-free HTTP parser in the stdlib, or is that a bad idea? Do we want
a PEP? Is there something we could add to PEP 8?

On Mon, Aug 8, 2016 at 2:45 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
> 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
>
>
>
> _______________________________________________
> Async-sig mailing list
> Async-sig at python.org
> https://mail.python.org/mailman/listinfo/async-sig
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)