It did surprise me also. Because I've come to Python from Delphi.
There are no return statement in Delphi.
I also write some c++, the language has no finally-statement. This
problem probably python exclusive.
I think it's not too difficult to get used to it. This behavior is fine
for me.
[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
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 article
you're
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,
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 a big fan of
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 template that
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 distinct
[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
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
[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:
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 convinced
[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
[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
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
used to
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
[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
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
- separation of EXPR and
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.
snip
* Automatically roll back partially-done
[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. It just
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* default,
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 chained
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
...
def catchit():
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 that this
[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 whether
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
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
to
[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 up
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
mostly
[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
except:
[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
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
mostly
31 matches
Mail list logo
