On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so > updating it with any of my ideas would be their call.
I'm willing to consider an update - I don't know Michael's view. I currently find myself in the odd situation of defending PEP 340 against PEP 310, though. I'll try to rationalise why below... > Either way, my latest and greatest version of the non-looping block statement > semantics can be found here: > http://mail.python.org/pipermail/python-dev/2005-May/053400.html I can't reconcile this description with that of PEP 310. The basic reason is that the styles are very different, compounded by the fact that I don't have the time to give this the analysis it needs. My instinct is that if your proposal can't be described in terms of a relatively small change to one of PEP 310 or 340, then my view is it's a 3rd proposal in its own right, and I'd rather not open things up that much again. > Some key advantages of that proposal are: > 1. It's not a loop, so nesting it inside another loop 'just works' This, to me, is the main issue > 2. Manual protocol implementations are _significantly_ easier to write Hmm, I've not tried so I'll have to take your word for this. But I don't imagine writing manual implementations much - one of the key features I like about Guido's proposal is that generators can be used, and the implementation is a clear template, with "yield" acting as a "put the block here" marker (yes, I know that's an oversimplification!). > 3. try/finally can be done with generators _without_ changing generators How is this an advantage? PEP 340 allows try/finally inside generators - if that counts as "changing generators" I don't see why I care (as a user). But I think I'm missing something here - I never really followed (or cared about) the generator finalisation issues. > 4. try/except/else can be done with generators if they provide an __exit__ > method that raises the exception at the point of the last yield As above - I'm not sure I follow. > 5. Clearly distinct construct, no potential for confusion with for loops OK, but that's really just saying "not a loop" again. > 6. Generators must be clearly marked as creating a user defined statement > (although this could be changed by giving them an __enter__ method and an > __exit__ method) I still don't see a compelling argument that this is a good thing. I'm neutral on this. > The one downside relative to PEP 340 is that looping constructs like > auto_retry > are slightly harder to write, albeit not hugely so (once you remember that an > iterable can be a class instead of a generator!). Are you *sure* that's the only downside? Early on in the PEP 340 discussion, generator finalisation was a point of discussion. I didn't follow the details, but I believe that one of the points of PEP 340 was that it addressed the issues (to some extent - I really don't know if the generator finalisation PEPs are rendered obsolete by PEP 340, are completely orthogonal, or somewhere in between). I have no feel for whether your proposal covers these issues in the same way as PEP 340 does. And does your proposal allow for "continue EXPR" as supported by PEP 340? I can't see that it could, given that your proposal treats block statements as not being loops. Having just noticed this, I start to feel less convinced that block-as-loop is ultimately wrong. There aren't any examples of continue EXPR included in PEP 340 yet - a fact that Guido has acknowledged in item 9 of the examples section. Maybe Philip or one of the other coroutine fans would like to contribute some examples? > On the usage front, I find the > 'loop over an iterator returning user defined statements' does a much better > job > of making the iteration clear, so I'd be inclined to count that as an > advantage > of a PEP 310 style approach. I can accept that. It's a minor style point either way. The wording of it - as "returning user defined statements" makes me nervous though, as it implies that "user-defined statements" are first class objects - which feels wrong. > Anyway, I've already been spending more time on this than I should (sleep is > optional, right?), so I won't be prettying it up into PEP format any time > soon. > I have no objection to someone else rolling some of the ideas into a PEP, > though :) I think *someone* has to care enough (and have the time) to make a proper PEP out of this. If it's a minor change to either of PEP 310 or PEP 340, that's OK. If it's too big for that, it needs to be fleshed out as a full competing PEP in its own right. Oh - and the promised rationalisation of my preference for PEP 340 over PEP 310. Things I like about PEP 340: - Using generators as "templates" with yield as a "put the block here" placeholder. It may be that a modification of PEP 310 can provide this, but that PEP doesn't exist yet (sorry!) - The coroutine style "continue EXPR" feature (I still need motivating examples but as a concept I like it). [It's interesting that these are the two points Guido notes as "orthogonal" concepts in PEP 340 - I don't apologise for this though, it's the whole package that appeals to me]. The looping behaviour is a (fairly nasty) wart, but I'm not sure I would insist on removing it at the cost of damaging other features I like. And I'm not entirely convinced that the desired behaviour of "break" might be achievable by special-casing break (but I don't have the time or understanding to flesh that out, so I have to accept that it may not happen). Paul. _______________________________________________ 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
