[Python-Dev] PEP 343 - Abstract Block Redux

[Greg Ewing]

Guido van Rossum wrote:

> But then the reason for separating VAR from EXPR becomes unclear.
> Several people have mentioned that they thought this was "a good idea
> on its own", but without giving additional use cases. Without the
> ability to write the acquire/release template as a generator, the big
> question is, "why not just PEP 310" ?

Here's another use case:

In PyGUI, in order to abstract the various ways that
different platforms deal with drawing contexts, my
widgets currently have a method

   widget.with_canvas(func)

where you define func as

   def func(canvas):
     # do drawing operations on the canvas

The canvas is a separate object from the widget so
that it's harder to make the mistake of trying to
draw to the widget outside of the appropriate context.

The with-statement form of this would be

   with widget.canvas() as c:
     # do drawing operations on c

Keeping the VAR and EXPR separate in this case better
reflects the semantics of the original with_canvas()
function. The canvas is strictly a local object
produced as a result of executing the __enter__
method, which helps ensure that the correct protocol
is followed -- if you haven't called __enter__, you
don't have a canvas, so you can't do any drawing.

On the other hand, this leads to some awkwardness
in the naming conventions. The canvas() method,
despite its name, doesn't actually return a canvas,
but another object which, when used in the right
way, produces a canvas.

In general, the names of methods for use in a
with-statement will need to be named according
to the object which is bound to the VAR, rather
than what they actually return.

I'm not sure whether this is a problem or not.
There's already a similar situation with generators,
which are more usefully named according to what
they yield, rather than what they return when
considered as a function. I just feel a bit
uncomfortable giving my widgets a function called
canvas() that doesn't return a canvas.

The alternative is that the canvas() method *does*
return a canvas, with __enter__ and __exit__
methods, and the rule that you have to use the
appropriate protocol before you can use it. This
would avoid most of the aforementioned problems.

So I think I may have just talked myself out of
what I was originally intending to argue!

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+