Trio is a big step forward in asynchronous programming IMHO. It's hard to capture its many concepts in such a short talk. If anyone wants to know more, Mr Smith's great blog posts on structured concurrency and cancel scope the place to start.
Very very helpful talk, thank you. Now I get the feeling that I can implement "Happy Eye Balls" and some other things I did in Rxjs. I'm going to try Trio right now.
Just stumbling over trio - question to you: did you try trio? I still like the declarative approach of Rx and was thinking of using Rx in Python as well. Would you say trio is "better", for many use cases?
Consider the case where an exception is stating that the process has an unbound resource. One of its ancestors should have the opportunity to bind something to that resource so the descendant has a chance to finish its work before it is killed. That is the closing of the child processes is contingent upon the exception being unresolved.
I wish Mr. Smith had spent more time explaining what's going on in the diagram at 19:28 He then jumps to some code where nothing is labeled "nursery" at 19:32 I know he was given a very short window to speak, but the idea of a nursery seems pretty important and I still don't quite get it.
Ah yeah, that bit at 19:32 is kinda unclear, isn't it? It was pretty tough describing the whole "theory of nurseries" in 5 minutes :-). If you want a more leisurely version, I'd recommend this blog post: vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ But about the slide at 19:32 in particular: The point I was trying to make is that in a lot of systems (e.g., twisted, asyncio), a function like proxy_two_way() might just start the proxying happening in the background, so when the function returns, you don't really know whether it's still running. So, just looking at the code on that slide, we can't tell whether it's safe to close the stream handles we passed in -- it might still be using them! But in Trio, we know it's safe to close the handles, *even if we have no idea what proxy_two_way actually does.* It might open a nursery internally, but then it has to close that nursery again before it returns, which means that any tasks it spawns have to be finished before it returns. (And in fact if you look at the complete code, at 9:05, then you'll see that it does open a nursery internally!) Because Trio mandates the use of nurseries, the only way proxy_two_way could leave things running after it returns is if we *pass in* a nursery object, and just from the code on the slide at 19:32 we can see that we're not. Hope that helps! (And sorry for the slow response, I don't get any notification of comments here. If you have more questions, then gitter.im/python-trio/general is a better place to reach me and the other Trio devs :-).)
*Hope that helps! (And sorry for the slow response* LOL! You better be sorry for writing such a helpful, informative response! Now get back to making more open source software that I'll probably use to make my life easier! Man... complaining about stuff on the internet is such a thankless job ;) Honestly, though. This is a fantastic response and I look forward to seeing how Trio develops! I might even pitch in!
:-) > I might even pitch in! That would be awesome. It turns out reinventing I/O and concurrency is kind of a big job, so there's no shortage of places to help :-). If you're interested, we have a handy contributing guide: trio.readthedocs.io/en/latest/contributing.html
coding for concurrency is my challenge-problem too, @@nathanielsmith2547 because I have an interest in maker projects (e.g. Arduino-Pi) that require its control at the sub-second (mHz, GHz) level of frequencies Makes me think what do RU-vid use, and shouldn't RU-vid be sponsoring the work of your community?
Somehow the syntax just seems unnatural to me when you say sink.send_eof( ) or sink.send_all(data). Makes it sound like as if sink is the one doing some work, when in fact we want to say "send all data TO sink" or "send an eof to sink". Perhaps a syntax like *trio.send_eof(sink)* or *trio.send_all(data, sink)* would be more intuitive.
I think the usage of the word 'sink' as the object name here is very deliberate, to make it implicitly tell you that it isn't actually doing anything itself - just passing through something - like a real sink just passing water through to whatever is at the end of the piping on the other side. Thinking like this makes the usage pretty clear for me.
