{"action":"created","issue":{"url":"https://api.github.com/repos/python-trio/trio/issues/504","repository_url":"https://api.github.com/repos/python-trio/trio","labels_url":"https://api.github.com/repos/python-trio/trio/issues/504/labels{/name}","comments_url":"https://api.github.com/repos/python-trio/trio/issues/504/comments","events_url":"https://api.github.com/repos/python-trio/trio/issues/504/events","html_url":"https://github.com/python-trio/trio/issues/504","id":315424471,"node_id":"MDU6SXNzdWUzMTU0MjQ0NzE=","number":504,"title":"Should we rename nurseries?","user":{"login":"njsmith","id":609896,"node_id":"MDQ6VXNlcjYwOTg5Ng==","avatar_url":"https://avatars0.githubusercontent.com/u/609896?v=4","gravatar_id":"","url":"https://api.github.com/users/njsmith","html_url":"https://github.com/njsmith","followers_url":"https://api.github.com/users/njsmith/followers","following_url":"https://api.github.com/users/njsmith/following{/other_user}","gists_url":"https://api.github.com/users/njsmith/gists{/gist_id}","starred_url":"https://api.github.com/users/njsmith/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/njsmith/subscriptions","organizations_url":"https://api.github.com/users/njsmith/orgs","repos_url":"https://api.github.com/users/njsmith/repos","events_url":"https://api.github.com/users/njsmith/events{/privacy}","received_events_url":"https://api.github.com/users/njsmith/received_events","type":"User","site_admin":false},"labels":[{"id":523592585,"node_id":"MDU6TGFiZWw1MjM1OTI1ODU=","url":"https://api.github.com/repos/python-trio/trio/labels/design%20discussion","name":"design discussion","color":"0052cc","default":false},{"id":538689361,"node_id":"MDU6TGFiZWw1Mzg2ODkzNjE=","url":"https://api.github.com/repos/python-trio/trio/labels/potential%20API%20breaker","name":"potential API breaker","color":"b60205","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":45,"created_at":"2018-04-18T10:35:35Z","updated_at":"2018-08-30T19:39:59Z","closed_at":null,"author_association":"MEMBER","body":"OK, let's do this.\r\n\r\nQuestion: Should we rename \"nurseries\"? It's something that keeps coming up, and while it would be somewhat painful to change now, it'll be pretty much impossible within the next 6 months... so I guess now is the time to have a discussion, and if we decide not to change it then this can at least become the canonical issue that we link people to when they ask about it.\r\n\r\nThe most common version of this complaint is something like: \"ugh, nursery is so cutesy. What about `TaskGroup`, or `WaitGroup`, or `TaskScope`, or something like that?\" I don't find this version of the complaint compelling, so let me start by explaining why that is.\r\n\r\nNames like `TaskGroup`, or `TaskScope` are excellent names for ordinary classes, the kinds of name we invent every day. For that kind of class, you want something that's descriptive, because you have a lot of them and people don't spend much time with any given one. And of course you want to follow the conventions, so the camelcase itself is informative: even if you aren't familiar with the particular class in question, you at least can tell at a glance that it *is* a class.\r\n\r\nNurseries, though, are a different kind of thing entirely. They're a new fundamental concept: you have to learn them up front, like you have to learn about `for` loops, and functions, and the difference between an object attribute and a local variable. Once you've used them for a few days, they recede into the background as part of your basic vocabulary. And they're just *different* from the concepts most people already know, so trying to give them a familiar descriptive name is actually misleading: you *have* to look them up and learn them. So, I want a name that feels like a primitive, like \"for\" or \"function\" or \"variable\" – something short and lowercase. And if anything, something that's a bit opaque and unfamiliar is probably better, because it signals \"hey, new concept here\". You can't have a lot of concepts like that, but nurseries are carrying an entire programming paradigm on their shoulders, so I think 1 new word is within our budget.\r\n\r\nAnd regarding it being \"cutesy\": This doesn't really bother me, given that (1) this is a domain where \"reaping orphan zombie children\" is already considered totally ordinary technical language, and (2) after you use nurseries for a few minutes the name stops feeling cutesy, just like you stopped noticing that \"trees\" have nothing to do with botany, \"functions\" often don't function (little debugging joke there), \"threads\" have nothing to do with textiles, etc. So like... ok, it's a bit cutesy but whatever, people will get over it. And being cutesy actually has some upside: the whole joke about \"a nursery is where child tasks live\" probably does help it stick in people's minds. OTOH, I'm not like super attached to having a cutesy name either; I think it's mostly a neutral attribute.\r\n\r\nSo that's why I'm convinced that \"nursery\" is better than `TaskGroup` or similar.\r\n\r\nBut...... when talking to @graydon about this today, I did have some doubts about \"nursery\", for two reasons. The first is, he pointed out that \"nursery\" is also used as jargon for generational garbage collectors (to refer to the youngest generation, which often gets special handling). So a language implementer might ask \"is this task in that nursery?\", and \"is this `Task` in the nursery?\" and those are two completely unrelated questions. Fortunately it's mostly implementers who encounter the GC version of nursery, but still... this is a legitimate collision.\r\n\r\nAnd the other is, I realized that the name is actually a bit less apropos since #375 landed and we tweaked the nursery semantics. Originally, I really wanted to emphasize the idea of \"supervision\", because we had the whole \"parenting is a full time job\" rule where the parent task had to park itself at the end of the nursery block or exceptions wouldn't propagate and stuff. Now the supervision part has dissolved into becoming an implicit part of the runtime, and doesn't really exist as a concept at all anymore – it's just, like, exceptions propagate themselves, what is there to talk about. The code inside the nursery block is just a slightly-special child. So that part of the metaphor has become a bit weird.\r\n\r\nSo here's another idea: maybe we could use a name that emphasizes that this is a place where your call stack splits/branches/words like that. Like, `async with trio.open_split()`, or `open_branchpoint`, or something like that? With the metaphor being that first you make a note \"here's a point in my call stack where child tasks might split off\", and then calling `start_soon` actually attaches a new branch there. I'm imagining like a hinge or a hook or something.\r\n\r\nAnyway, that's just one idea – if y'all have other ideas I'd be interested to hear them, and ditto any thoughts on how the \"nursery\" name worked for you as either a newcomer to Trio or as you've become more experienced."},"comment":{"url":"https://api.github.com/repos/python-trio/trio/issues/comments/417442601","html_url":"https://github.com/python-trio/trio/issues/504#issuecomment-417442601","issue_url":"https://api.github.com/repos/python-trio/trio/issues/504","id":417442601,"node_id":"MDEyOklzc3VlQ29tbWVudDQxNzQ0MjYwMQ==","user":{"login":"belm0","id":1708631,"node_id":"MDQ6VXNlcjE3MDg2MzE=","avatar_url":"https://avatars3.githubusercontent.com/u/1708631?v=4","gravatar_id":"","url":"https://api.github.com/users/belm0","html_url":"https://github.com/belm0","followers_url":"https://api.github.com/users/belm0/followers","following_url":"https://api.github.com/users/belm0/following{/other_user}","gists_url":"https://api.github.com/users/belm0/gists{/gist_id}","starred_url":"https://api.github.com/users/belm0/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/belm0/subscriptions","organizations_url":"https://api.github.com/users/belm0/orgs","repos_url":"https://api.github.com/users/belm0/repos","events_url":"https://api.github.com/users/belm0/events{/privacy}","received_events_url":"https://api.github.com/users/belm0/received_events","type":"User","site_admin":false},"created_at":"2018-08-30T19:39:59Z","updated_at":"2018-08-30T19:39:59Z","author_association":"MEMBER","body":"I came up with \"task scope\" independently from reading the opening post.  I think it's close to ideal.  (\"Execution scope\" is arguably more accurate, but also more letters.)\r\n\r\nWhen you consider practical usage, it's a clear win over \"nursery\".  In practice you'd like a short name for accessing the nursery, but `n` is not prudent.  Proposed idiom for task scope using `ts`:\r\n```\r\nasync with trio.open_task_scope() as ts:\r\n    ts.run_soon(...)\r\n```"}}
{"actor":{"display_login":"belm0"}}