[Python-Dev] PEP 343 - Abstract Block Redux

Nick Coghlan ncoghlan at gmail.com
Mon May 16 14:25:49 CEST 2005


Paul Moore wrote:
> I'm not sure I agree with that - to me, PEP 340 felt like the
> consolidation of the previous discussion. My feeling was "cool - we've
> had the discussion, now we've formalised the results, maybe a few
> details to tidy up and then we can see the implementation being
> checked in". Then Nick's proposal *failed* to feel like the tidying up
> of the details, and PEP 343 felt like giving up on the powerful (but
> hard) bits. It's all people's impressions, though, so maybe I'm just
> bitter and cynical :-)

Actually, I agree that the early versions of my proposal failed to tidy things 
up (I was honestly trying - I just didn't succeed).

I'm pretty happy with the version I just submitted to the PEP editors, though:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html

It gives generators inherent ``with`` statement support in order to handle 
finalisation (similar to the way it suggests files support the ``with`` 
statement in addition to ``for`` loops).

An appropriately defined decorator then provides the ability to write ``with`` 
statement templates using the PEP 340 generator-based style.

>>I'd be surprised if you can find many examples that PEP 340 can do
>>that PEP 3XX can't.
> 
> In which cask, Nick is "marketing" it really badly - I hadn't got that
> impression at all. And if Nick's proposal really *is* PEP 340 with the
> issues people had resolved, how come Guido isn't supporting it?

I think this is because I've been changing it too fast. This is also the main 
reason I hadn't submitted before now - *I* wasn't happy with it, so I wanted to 
keep it easy to update for a while longer.

I hope that the version that appears on python.org will garner a bit more 
support. I submitted it because I finally felt I'd achieved what I set out to do 
(cleanly integrate PEP 310 and PEP 340), whereas none of my previous drafts felt 
that way.

> Also, the discussion has moved to resource objects with special
> methods rather than generators as templates - which I see as a direct
> consequence of PEP 342 being excluded. One of the things I really
> liked about PEP 340 was the "generator template" style of code, with
> yield as the "block goes here" placeolder

My PEP suggests simple cases are best handled by __enter__/__exit__ methods 
directly on the classes (for efficiency, ease of use, and to avoid cluttering 
the builtin namespace), but more complex cases (like acquiring two locks, or 
using a particular lock to protect access to a certain file) be handled using 
PEP 340 style generator templates.

> In my view, *every* PEP 340/343/3XX example when written in generator
> form counts as a good example (see above). Neat coroutine tricks and
> the like are the "additional benefits" - maybe bordering on abuses in
> some cases, so I don't want to focus on them in case we get into
> arguments about whether a feature is bad simply because it *can* be
> abused... But the key use case, for me, *is* the generator-as-template
> feature.

PEP 342 isn't about the ability to inject exceptions into generators - it's 
about yield expressions and enhanced continue statements. We haven't actually 
identified any use cases for those yet (I'm wondering if there is some way to 
use the idea to implement accumulators, but getting the final result out is a 
real challenge)

PEP 340 and my PEP are the two PEP's which talk about injecting exceptions in 
order to write nice statement templates. PEP 288 is the one which would make 
that mechanism available to Python code.

> Which is why I regret that Guido didn't just go ahead and implement
> it, consensus be damned :-) I vote for a dictatorship :-)

Nah, we'll get something good at the end of it anyway - and this way we'll 
*know* it's good :)

>>Ok, back to summarizing this fortnight's 380+ PEP 340 messages. ;-)
> 
> Best of luck - and in case you need a motivation boost, can I just say
> that this sort of thread is why I have the greatest respect and
> appreciation for the job the summarisers do.

Oyah. I had a hard enough time just identifying all the ideas I wanted to 
discuss in the "Rejected Options" section of my PEP.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com


More information about the Python-Dev mailing list