
On 17.06.2017 17:51, Nick Coghlan wrote:
You've pretty much hit on why that PEP's been deferred for ~5 years or so - I'm waiting to see use cases where we can genuinely say "this would be so much easier and more readable if we had a given construct!" :)
This PEP accepted, we would have 3 ways of doing 1 thing (imperative programming): 1) flat inline execution namespace 2) structured inline execution namespace 3) named code used in 1) oder 2) Is that simple enough for Python? Just one side thought: internally, we have a guideline which says: "please reduce the number of indentations" -> less else, less if, less while, etc. The goal is more compact, less complex code. Our code is already complex enough due to its sher amount. "given" would fall under the same rule here: keep it flat and simple; otherwise, give it a name.
Then asyncio (and variants like curio and trio) came along and asked the question: what if we built on the concepts explored by Twisted's inlineDeferred's, and instead made it easier to write asynchronous code without explicitly constructing callback chains?
Does it relate? I can imagine having both "given" and "async given".
However, in my own work, having to come up with a sensible name for the encapsulated operation generally comes with a readability benefit as well, so...
Well said. In the end (when it comes to professional code), you need to test those little things anyway. So addressing them is necessary. In interactive code, well, honestly, I don't care so much about spoiling namespaces and using variables names such as 'a' or 'bb' is quite common to try things out. @Steven Good post, thanks for explaining it. :) Might be too much for the simple Python I know and value but hey if it helps. Maybe it will enable a lot of cool stuff and we cannot imagine right now just because David Beazley cannot try it out in practice. Regards, Sven