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 <c...@lukasa.co.uk> wrote: > On 8 Aug 2016, at 07:56, Yarko Tymciurak <yark...@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@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) _______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
