[Python-ideas] A different kind of context manager

[Kristján Valur Jónsson]

Thanks for your detailed reply, Nick.
Good to see that I am not completely bonkers and that swimming entirely alone against the flow.
I realise of course that we are Python and not Ruby (I got to learn Ruby before Python, btw) and that this is not particularly likely to come to anything.

But remember how Python retro-fitted Ruby's object model into its "new-style" classes?  Ruby was written that way all along.  (CS buffs out there will likely point out to me that this was not an original Matz invention).
Perhaps, with persistent dripping, we can slowly hollow the proverbial stone.

Cheers,

K

From: Nick Coghlan [mailto:ncoghlan at gmail.com]
Sent: 22. október 2013 03:32
To: Haoyi Li
Cc: python-ideas at python.org; Kristján Valur Jónsson
Subject: Re: [Python-ideas] A different kind of context manager


On 22 Oct 2013 07:27, "Haoyi Li" <haoyi.sg at gmail.com<mailto:haoyi.sg at gmail.com>> wrote:
>
> > Maybe we should have selected one in which this sort of coding is its native, natural, form, rather than having this intermarriage kludge which turns an imperative-looking generator into the traditional context manager.
>
> I agree with this 100%. Unfortunately, Python picked the current style of `with` statements a while ago, and this would be a pretty huge change/additional feature.
>
> FWIW, other languages with easy anonymous functions (e.g. ruby, scala) have this, and it does provide all the benefits that you describe. For example, spinning off parallel tasklets inline is just a matter of `async{ ... }` where `async` is just a context manager.

It's not a coincidence that Ruby (at least - I don't know scala) just treats for loops and context management as special cases of anonymous callbacks - the latter is a powerful, more general construct.

By contrast, Python chose the path of providing dedicated syntax for both iteration *and* context management, and hence requires that callbacks that don't fit in a single expression be defined prior to use.

I think this makes those constructs easier to understand in many ways, but it *also* means that we *don't* currently have a clean syntax for single use callbacks.

Hence the time I've put into PEP 403 and 3150 over the years - a key objective for both of them is providing a cleaner solution for the problem of single use callbacks (including those that modify local variables of the containing function).

In addition to scoping, the other problem single use callbacks need to handle sensibly is the behaviour of the simple flow control statements: return, yield, break, continue, and raise.

Building single use callbacks on top of the "def" statement has the advantage of *not* needing to define any new scoping or control flow semantics (as they're just ordinary nested scopes).

Defining them any other way makes things far more complicated. It would certainly be close to impossible to repurpose any of the other existing compound statements without breaking backwards compatibility.

A completely new keyword is also a possibility, but then it's necessary to find a good one, and explain it's use cases in a fashion similar to PEP 403.

Cheers,


>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org<mailto:Python-ideas at python.org>
> https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131023/03e00bba/attachment.html>