Thanks Cory - I wasn't so much saying "Isn't Cory doing kinda what Brandon said" as I was saying "Isn't this kinda the more general stuff that Bob Martin talks (tries to talk about?) with Clean Architechture / Clean Coding (which Brandon - first I saw explicitly - shows a bit of examples of in the Python context in his PyOhio, and how that helps testability ... and I suppose maintainability).
So, less than my intending to point-to / assign credit (credit is due _everywhere_, honestly great stuff abounds!), I was hoping to say "hey - we've just scratched the surface - we can take this more broadly!" For me, the interesting question (in looking at what coding errors I've seen which opened my eyes to all this, as entangled as they've been in several kinds all mixed in) - isn't async in general one of these elements with potential for "clean", for thinking about taking it further in python, in effect doing with the language sort of a similar thing which Cory has demonstrated w/ protocols? I don't know, but I am curios (pun not intended). Dave Beazley's curio (which I had the pleasure of saying "quit talking, show me running code!" early on - and then "wow!"), and other things are leading me to think our / Python community's perspective on async might (?) need a bigger shift, a bigger kick-out-of-current-ways-of-thinking. Yury's comment "you mean put async into the core, like go?" was probably spot on as far as understanding my thinking - but not to mimic, but rather to honestly explore the bigger library implications - maintenance and simplicity and performance - and the "keeping-you-out-of-trouble" effect that (hopefully) might exist for application coders. At this year's PyOhio, Dave mentioned a project moving from python to go because of this. I saw in enough (?) detail the "technical" reasons why (I think errors in managing cooperative multi-tasking, which async is - and never spotting the real problem), and I gasped, and so started some side discussions with several of you. So - to everyone - thanks for all the discussion, and thinking, and presenting, and break-away libraries. I hope we keep kicking this ball around a bit more, into new, deeper space! - Yarko On Mon, Aug 8, 2016 at 7:26 AM, David Beazley <d...@dabeaz.com> wrote: > > > On Aug 8, 2016, at 4:45 AM, Cory Benfield <c...@lukasa.co.uk> wrote: > >> > > > > 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. > > > > Chiming in on the "zeitgeist" comment for a moment, I've wondered for a > long time why Python can't reinvent itself in the area of I/O (and maybe > systems programming generally). Honestly, I feel like a whole lot of > time has been burned up thinking about Python 2/3 compatibility instead of > looking forward with futuristic new projects and ideas. Perhaps > "async/await" serves as a catalyst to rethink some of these things. A lot > of my work with async/await is really focused on exploring the API space > with it--well, at least seeing how much I can twist that part of the > language in diabolical ways. The protocol issue is real though. Sure, I > could probably bang out a passable HTTP/0.9 protocol in an afternoon, but > try to tackle something modern like HTTP/2? No way. I'm totally out of > my element with something like that. Having an I/O-free implementation of > it is cool. It would be pretty neat to have something like that for > various other things too (Redis, MySQL, postgres, ZeroMQ, etc.). > > Cheers, > Dave > >
_______________________________________________ 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/
