[Fredrik Lundh] > intuitively, I'm -1 on this proposal. So we need to do better. Do you just prefer all of PEP 340? What about the objections against it? The mostly unnecessary loopiness in particular?
> unlike the original design, all you get from this is > the ability to add try/finally blocks to your code > without ever writing a try/finally-clause (neither > in your code or in the block controller). that > doesn't strike me as especially pythonic. Would it be better if we pulled back in the generator exit handling from PEP 340? That's a pretty self-contained thing, and would let you write try/finally around the yield. > (neither does the argument that just because you > can use a mechanism to write inscrutable code, > such a mechanism must not be made available > feel right; Python's design has always been about > careful tradeoffs between policy and mechanism, > but this is too much policy for my taste. the > original PEP 340 might have been too clever, but > this reduced version feels pretty pointless). Maybe. It still solves the majority of use cases for PEP 340, most of which are try/finally abstractions. Maybe I'm overreacting to Raymond Chen's rant about flow-control macros -- but having had to maintain code once that was riddled with these, it rang very true. PEP 340 is still my favorite, but it seems there's too much opposition to it, so I'm trying to explore alternatives; at the same time I *really* dislike the complexities of some of the non-looping counterproposals (e.g. Nick Coghlan's PEP 3XX or the proposals that make every keyword associated with 'try' a method). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
