Re: [Python-Dev] PEP 343 - Abstract Block Redux

Guido van Rossum wrote: > I've written up the specs for my "PEP 340 redux" proposal as a > separate PEP, PEP 343. > > http://python.org/peps/pep-0343.html > > Those who have been following the thread "Merging PEP 310 and PEP > 340-redux?" will recognize my proposal in that thread, which received

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Bill Janssen] > I agree. "with [VAR =] BLOCK:" just reads better. "with BLOCK [as > VAR]:" is OK, too. Maybe someone can set up a public poll (isn't that something you can do on Yahoo? Or some volunteer can probably write it in Zope in 3 minutes) asking whether people prefer 'do' or 'with'. I'l

Re: [Python-Dev] PEP 343 - Abstract Block Redux

[Nick Coghlan] > The stdout redirection example needs to be corrected to avoid yielding inside > a > try/finally though: Thanks -- fixed now. > This could be left as the more elegant original if iterator finalisation (e.g. > using a "__finish__()" slot) came in at the same time as user defined >

Re: [Python-Dev] PEP 343 - Abstract Block Redux

[Phillip J. Eby] > May I suggest this alternative translation in the "Specification" section: > > abc = EXPR > __args = () # pseudo-variable, not visible to the user > > try: > VAR = abc.__enter__() > try: > BLOCK >

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

> I prefer 'with'. The 'do' keyword sounds "loopy" and doesn't make > grammatical sense. I agree. "with [VAR =] BLOCK:" just reads better. "with BLOCK [as VAR]:" is OK, too. Or even "within", as in within BLOCK binding VAR: SOMETHING Probably too techy. Bill

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

On Fri, 13 May 2005, Guido van Rossum wrote: > Straight up-or-down votes in the full senate are appreciated at this point. I prefer the "PEP 340 redux" version. Both the flexibility for __enter__ to return a separate object and the ability for __exit__ to react to exceptions are useful. > - Toda

Re: [Python-Dev] PEP 343 - Abstract Block Redux

Guido van Rossum wrote: > I've written up the specs for my "PEP 340 redux" proposal as a > separate PEP, PEP 343. > > http://python.org/peps/pep-0343.html > > Those who have been following the thread "Merging PEP 310 and PEP > 340-redux?" will recognize my proposal in that thread, which received

Re: [Python-Dev] PEP 343 - Abstract Block Redux

At 05:13 PM 5/13/2005 -0700, Guido van Rossum wrote: >I've written up the specs for my "PEP 340 redux" proposal as a >separate PEP, PEP 343. > >http://python.org/peps/pep-0343.html > >Those who have been following the thread "Merging PEP 310 and PEP >340-redux?" will recognize my proposal in that t

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Greg Ewing] > -0.7 on directly giving generators do-protocol methods. I'm -1 on this myself. > I'm not yet convinced that encouraging people to use > generators to implement block controllers is a good > idea. If we blur the distinction too much at this > stage, we may regret it later if we come

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum wrote: > BTW, we need a name for such a decorated generator that only yields > once. I propose to call it a degenerator. Cute, but 'template generator' may be clearer (that's what I've been calling them so far, anyway). Then 'iterator generator' can be used to explicitly refer t

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Here's my vote on things at the moment: +1 on do EXPR as VAR: ... +1 on keeping the EXPR and VAR distinct. +1 on keeping the do and generator protocols distinct. +1 on not going out of our way to let the controller catch exceptions or alter control flow. Let's keep it as simple as we c

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum] > > So then the all-important question I want to pose is: do we like the > > idea of using a (degenerate, decorated) generator as a "template" for > > the do-statement enough to accept the slightly increased complexity? [Greg Ewing] > I can't see how this has anything to do with

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum wrote: > So then the all-important question I want to pose is: do we like the > idea of using a (degenerate, decorated) generator as a "template" for > the do-statement enough to accept the slightly increased complexity? I can't see how this has anything to do with whether a gener

[Python-Dev] PEP 343 - Abstract Block Redux

I've written up the specs for my "PEP 340 redux" proposal as a separate PEP, PEP 343. http://python.org/peps/pep-0343.html Those who have been following the thread "Merging PEP 310 and PEP 340-redux?" will recognize my proposal in that thread, which received mostly positive responses there. Plea

Re: [Python-Dev] Chained Exceptions

[Brett C.] > Maybe, but as long as caught exceptions get cleared that should be an issue. > Would this be solved if, when an 'except' branch is exited, exceptions are > cleared? So, in the above example, once the 'pass' is hit in catchit() no > exception is considered active any longer. This coul

Re: [Python-Dev] Python's Unicode width default (New Py_UNICODE doc)

Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>I'm not breaking anything, I'm just correcting the >>way things have to be configured in an effort to >>bring back the cross-platforma configure default. > > Your proposed change will break the build of Python > on Redhat/Fedora systems. You know

Re: [Python-Dev] Chained Exceptions

Guido van Rossum wrote: > [Guido] > >>>What if that method catches that exception? > > > [Ka-Ping Yee] > >>Did you mean something like this? >> >>def handle(): >>try: >>open('spamspamspam') >>except: >>catchit() >># point A >>.

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

+1 PEP 340 redux (although I marginally prefer the "with" keyword) Guido van Rossum wrote: > So then the all-important question I want to pose is: do we like the > idea of using a (degenerate, decorated) generator as a "template" for > the do-statement enough to accept the slightly increased compl

Re: [Python-Dev] Tidier Exceptions

Guido van Rossum wrote: > [Ka-Ping Yee] > >>Maybe bare 'except' should be spelled 'except *'. > > > -1. > > >>I don't think it can be removed altogether because sometimes you just >>need to be able to do magic, but it can be made a little more explicit. > > > Assuming a single root of the ex

Re: [Python-Dev] Tidier Exceptions

Guido van Rossum wrote: > [Brett C.] > >>Seems like, especially if we require inheritance from a base exception class >>in >>Python 3000, exceptions should have standard 'arg' and 'traceback' attributes >>with a possible 'context' attribute (or always a 'context' attribute set to >>None if not a

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum wrote: [SNIP] > Straight up-or-down votes in the full senate are appreciated at this point. > PEP 340 redux gets my +1; I think using generators will become more obviously useful to people when, as Fredrick pointed out, your code grows more than a few lines long. > On to the sec

Re: [Python-Dev] Python's Unicode width default (New Py_UNICODE doc)

M.-A. Lemburg wrote: > I'm not breaking anything, I'm just correcting the > way things have to be configured in an effort to > bring back the cross-platforma configure default. Your proposed change will break the build of Python on Redhat/Fedora systems. > I'm talking about the *configure* defaul

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Nick Coghlan] > However, I'm fine with declaring that, from the perspective of a statement > template, 'return', 'break' and 'continue' are all 'non-exceptional exits', > and > so templates like transaction() are expected to treat them as such. Me too. The argument that made me realize this is o

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum] > > Cons: > > - slightly less simple (__enter__ must return something for VAR; > > __exit__ takes optional args) [Fredrik Lundh] > what happened to the original "yield the target object" solution? or did > I just dream that? Don't worry, that works when you use a generator.

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Phillip J. Eby wrote: > At 08:41 AM 5/13/2005 -0700, Guido van Rossum wrote: > >>The 'oke' argument is so that the author of transactional() can decide >>what to do with a non-local goto: commit, rollback or hit the author >>over the head with a big stick. > * Automatically roll back partially-do

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum wrote: > PEP 340 redux > = > > Syntax: > do EXPR [as VAR]: > BLOCK > > Translation: > abc = EXPR > [VAR =] abc.__enter__() > try: > BLOCK > finally: > abc.__exit__(*"sys.exc_info()") # Not exactly > > Pros: > - can use a decorated generator as EXPR > - sepa

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Nick Coghlan] > The ban on yielding inside try/finally will need to be extended to yielding > inside user defined statements until such time as an iterator finalisation > protocol is chosen, though. Ah! Good point. This breaks PEP 340 example 5. No big deal, but worth noting. -- --Guido van Ros

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Michael Hudson wrote: > Looking at my above code, no (even though I think I've rendered the > point moot...). Compare and contrast: > > @template > def redirected_stdout(out): > save_stdout = sys.stdout > sys.stdout = out > > yield None > > sys.stdout = save_stdout > > class redir

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum wrote: > I just read Raymond Chen's rant against control flow macros: > http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx > > I think this pretty much kills PEP 340, as well as Nick Coghlan's > alternative: both proposals let you write a "template" that can be > use

[Python-Dev] Pre-PEP: Unifying try-except and try-finally

[Guido] >>> Can I go ahead and approve this now? [Michael Hudson] >> While I see the cost of this PEP being pretty small, I see the benefit >> the same way too. [Guido] > Sure. Let me approve it and we'll see if someone cares enough to implement it. No one will scream if you approve it, but when

Re: [Python-Dev] "with" use case: replacing a file

Phillip J. Eby wrote: > At 07:23 PM 5/13/2005 +1000, Nick Coghlan wrote: >> Sorry about that (I was in a hurry this morning). It was here: >> http://www.joelonsoftware.com/articles/Wrong.html > > "Wrong" is an excellent title for that article; it's completely > wrongheaded about exceptions. :)

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Steven Bethard] > +0. I'm not thoroughly convinced that generators are that much easier > to read than a class. But I don't find them hard to read, and I think > it would only take a little effort to learn that generators might not > always be intended to build iterators. I am proposing (like P

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Guido] > >The 'oke' argument is so that the author of transactional() can decide > >what to do with a non-local goto: commit, rollback or hit the author > >over the head with a big stick. [Phillip J. Eby] > Since this is just a replacement for a try/except/finally block, I'd expect > that in a tr

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

On 5/13/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > So then the all-important question I want to pose is: do we like the > idea of using a (degenerate, decorated) generator as a "template" for > the do-statement enough to accept the slightly increased complexity? +0. I'm not thoroughly conv

Re: [Python-Dev] Tidier Exceptions

[Guido, on string exceptions] > ... > Last I looked Zope 2 still depended on them (especially in the > bowels of ZODB); maybe Tim Peters knows if that's still the > case. Certainly none of that in ZODB, or in ZRS. Definitely some in Zope 2.6:

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

At 08:41 AM 5/13/2005 -0700, Guido van Rossum wrote: >The 'oke' argument is so that the author of transactional() can decide >what to do with a non-local goto: commit, rollback or hit the author >over the head with a big stick. Since this is just a replacement for a try/except/finally block, I'd e

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

On 5/13/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Tastes differ. I think the generator wins; more so when there's more > state to remember. [...] > > > Straight up-or-down votes in the full senate are appreciated at this > > > point. > > > > +1 for the PEP 340 variant. I am also +1 for th

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Michael Hudson, after much thinking aloud] > Oh, I guess the point is that with a decorated generator you can yield > a value to be used as VAR, rather than just discarding the value as > here. Hmm. Right. (I thought it was worth quoting this for the benefit of other who went down the same trail

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

At 03:05 AM 5/13/2005 -0700, Guido van Rossum wrote: >So then the all-important question I want to pose is: do we like the >idea of using a (degenerate, decorated) generator as a "template" for >the do-statement enough to accept the slightly increased complexity? Since the "do protocol" is now dis

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

Guido van Rossum <[EMAIL PROTECTED]> writes: > I just read Raymond Chen's rant against control flow macros: > http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx > > I think this pretty much kills PEP 340, as well as Nick Coghlan's > alternative: both proposals let you write a "templa

Re: [Python-Dev] "with" use case: replacing a file

At 07:23 PM 5/13/2005 +1000, Nick Coghlan wrote: >Guido van Rossum wrote: > >>P.S. The points regarding non-local flow control in Joel Spolsky's > latest Joel > >>on Software article (especially the links at the end) may have had > something to > >>do with my change of heart. . . > > > > > > I'm

Re: [Python-Dev] Python's Unicode width default (New Py_UNICODE doc)

Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>Martin, please reconsider... the choice is between: > > > The point is that this all was discussed, and decided the > other way 'round. There is no point in going back and forth > between the two choices: > > http://mail.python.org/pipermail/pyt

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

I just read Raymond Chen's rant against control flow macros: http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx I think this pretty much kills PEP 340, as well as Nick Coghlan's alternative: both proposals let you write a "template" that can be used to hide exception-catching code, w

Re: [Python-Dev] "with" use case: replacing a file

Guido van Rossum wrote: >>P.S. The points regarding non-local flow control in Joel Spolsky's latest Joel >>on Software article (especially the links at the end) may have had something >>to >>do with my change of heart. . . > > > I'm a big fan of Joel. Care to share the specific URL for the artic

Re: [Python-Dev] Tidier Exceptions

[Greg Ewing] > Are there plans as to when string exceptions will be > exterminated? Surely the only places they're used now > are in some very old library modules. No concrete plans; I was always planning to abandon them in 3.0 but haven't felt the need to do it sooner. Last I looked Zope 2 still