Re: [Python-Dev] Example for PEP 343

[Nick Coghlan]

Guido van Rossum wrote:
> Anyway, perhaps we should provide this most general template:
> 
>   @do_template
>   def with_decimal_context():
>   oldctx = decimal.getcontext()
>   newctx = oldctx.copy()
>   decimal.setcontext(newctx)
>   yield newctx
>   decimal.setcontext(oldctx)
> 
> To be used like this:
> 
>   do with_decimal_context() as ctx:
>   ctx.prec += 2
>   # change other settings
>   # algorithm goes here


For the 'with' keyword, and the appropriate __enter__/__exit__ methods on 
decimal Contexts, this can be written:

   with decimal.getcontext() as ctx:
   ctx.prec += 2
   # change other settings
   # algorithm goes here
   # Pre-with context guaranteed to be restored here

The decimal.Context methods to make this work:

   def __enter__(self):
   current = getcontext()
   if current is self:
   self._saved_context = self.copy()
   else:
   self._saved_context = current
   setcontext(self)

   def __exit___(self, *exc_info):
   if self._saved_context is None:
   raise RuntimeError("No context saved")
   try:
   setcontext(self._saved_context)
   finally:
   self._saved_context = None

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
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

Re: [Python-Dev] Request for dev permissions

[Skip Montanaro]

Robert> P.S. Do you have a valid email address, RB? I wasn't able to fix
Robert> up your nospam address by hand.

That's because it didn't need fixing... Note Reinhold's sig:

Reinhold> -- 
Reinhold> Mail address is perfectly valid!



Skip
___
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

Re: [Python-Dev] Decimal construction

[Aahz]

On Wed, May 18, 2005, Tim Peters wrote:
>
> I think it shows more why it was a mistake for the decimal constructor
> to extend the standard (the string->decimal operation in the standard
> respects context settings; the results differ here because D(whatever)
> ignores context settings; having a common operation ignore context is
> ugly and error-prone).

Not sure what the "right" answer is, but I wanted to stick my oar in to
say that I think that Decimal has not been in the field long enough or
widely-enough used that we should feel that the API has been set in
stone.  If there's agreement that a mistake was made, let's fix it!
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier."  --JMS
___
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

Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

[Guido van Rossum]

Here's another rule-of-thumb: when the VM and the user *share* the
attribute space of an object, the VM uses system attributes; the VM
uses plain attributes for objects that it owns completely (like code
objects, frames and so on, which rarely figure user code except for
the explicit purpose of introspection). So I think the PEP should
continue to use __traceback__ etc.

On 5/17/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> 
> > Unfortunately I can't quite decide whether either rule applies in the
> > case of exceptions.
> 
> I think you'd at least be justified in using the "magic" rule,
> since they're set by the exception machinery.

-- 
--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

Re: [Python-Dev] Example for PEP 343

[Michael Chermside]

Phillip writes:
> >@do_template
> >def with_extra_precision(places=2):
> > "Performs nested computation with extra digits of precision."
> > decimal.getcontext().prec += 2
> > yield None
> > decimal.getcontext().prec -= 2
>
> Won't this do the wrong thing if something within the block alters
> the precision?

Depends on what behavior you want. I wrote it this way partly because
that's how the example in the manual was written, and partly because
I was thinking "if someone increased the precision by 3 within the
block, then we probably want to leave it increased by 3 on block
exit".

On careful re-consideration, I think it'd be better to require that
the block NOT make unbalanced changes to the precision... we
could verify it using an assert statement.

I avoided caching the context and restoring it, because I WANTED to
allow code in the block to make OTHER alterations to the context and
not clobber them after the block exits (eg: setting or clearing some
trap). It's debatable whether that was a good design choice... there's
a great deal of elegence to Guido's version used like this:

Guido:
>   do with_decimal_context() as ctx:
>   ctx.prec += 2
>   # change other settings
>   # algorithm goes here

However, all of these are minor details compared to the bug that
Raymond points out:

Raymond:
> The final "return +s" should be unindented.  It should
> be at the same level as the "do with_extra_precision()".  The purpose of
> the "+s" is to force the result to be rounded back to the *original*
> precision.

In effect, the "with_extra_precision" wrapper causes the calculations
to be done with higher precision, AND causes any variables set during
the block will retain their higher precision. (It's because context
controls OPERATIONS but changing context never affects individual
Decimal OBJECTS.) So I fear that the whole with_extra_precision()
idea is just likely to tempt people into introducing subtle bugs, and
it should probably be scrapped anyhow. Guido's approach to save-and-
restore context works fine.

-- Michael Chermside

(PS: Another reason that I avoided a basic save-and-restore is that we
have plenty of examples already of 'do' statements that save-and-restore,
I was trying to do something different. It's interesting that what I
tried may have turned out to be a poor idea.)

___
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

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Guido van Rossum]

I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX
(http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still
awaiting PEP moderator approval I believe?) the main difference is
that Nick proposes a way to inject an exception into a generator; and
I've said a few times that I like that idea.

I'd like to propose to make that a separate PEP, which can combine
elements of PEP 288 and PEP 325. Summary:

- g.throw(type, value, traceback) causes the specified exception to be
thrown at the place where the generator g is currently suspended. If
the generator catches the exception and yields another value, that is
the return value of g.throw(). If it doesn't catch the exception, the
throw() appears to raise the same exception passed it (it "falls
through"). If the generator raises another exception (this includes
the StopIteration produced when it returns) that exception is raised
by the throw. In summary, throw() behaves like next() except it raises
an exception at the place of the yield. If the generator is already in
the closed state, throw() just raises the exception it was passed
without going through the generator.

- There's a new exception, GeneratorExit, which can be thrown to cause
a generator to clean up. A generator should not yield a value in
response to this exception.

- g.close() throws a GeneratorExit exception in the generator, and
catches it (so g.close() itself does not raise an exception).
g.close() is idempotent -- if the generator is already closed, it is a
no-op. If the generator, against the rules, yields another value, it
is nevertheless marked closed.

- When a generator is GC'ed, its close() method is called (which is a
no-op if it is already closed).

That's it! With this, we can write the decorator from Nick's PEP 3XX
and the generator examples in PEP 343 can be rewritten to have a
try/finally clause around the yield statement.

Oh, somewhere it should be stated that yield without an expression is
equivalent to yield None. PEP 342 ("continue EXPR") already implies
that, so we don't have to write a separate PEP for it. I also propose
to go with the alternative in PEP 342 of using next() rather than
__next__() -- generators will have methods next(), throw(), and
close().

-- 
--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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby]

At 09:39 AM 5/18/2005 -0700, Guido van Rossum wrote:
>- g.throw(type, value, traceback) causes the specified exception to be
>thrown at the place where the generator g is currently suspended. If
>the generator catches the exception and yields another value, that is
>the return value of g.throw(). If it doesn't catch the exception, the
>throw() appears to raise the same exception passed it (it "falls
>through"). If the generator raises another exception (this includes
>the StopIteration produced when it returns) that exception is raised
>by the throw. In summary, throw() behaves like next() except it raises
>an exception at the place of the yield. If the generator is already in
>the closed state, throw() just raises the exception it was passed
>without going through the generator.
>
>- There's a new exception, GeneratorExit, which can be thrown to cause
>a generator to clean up. A generator should not yield a value in
>response to this exception.
>
>- g.close() throws a GeneratorExit exception in the generator, and
>catches it (so g.close() itself does not raise an exception).
>g.close() is idempotent -- if the generator is already closed, it is a
>no-op. If the generator, against the rules, yields another value, it
>is nevertheless marked closed.
>
>- When a generator is GC'ed, its close() method is called (which is a
>no-op if it is already closed).
>
>That's it! With this, we can write the decorator from Nick's PEP 3XX
>and the generator examples in PEP 343 can be rewritten to have a
>try/finally clause around the yield statement.
>
>Oh, somewhere it should be stated that yield without an expression is
>equivalent to yield None. PEP 342 ("continue EXPR") already implies
>that, so we don't have to write a separate PEP for it. I also propose
>to go with the alternative in PEP 342 of using next() rather than
>__next__() -- generators will have methods next(), throw(), and
>close().

And there was much rejoicing in the land of the co-routiney people.  :)  +1000.

Should this maybe just be added to PEP 342?  To me, PEP 342 has always 
seemed incomplete without ways to throw() and close(), but that could 
easily be just me.  In any case I'd expect the implementation of 
'next(arg)' to have some overlap with the implementation of 'throw()'.

Also, if the generator yields a value upon close(), shouldn't that throw a 
runtime error?  Otherwise, you have no way to know the generator's 
exception handling is broken.

___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Michael Sparks]

On Wednesday 18 May 2005 17:39, Guido van Rossum wrote:
> I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX
> (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still
> awaiting PEP moderator approval I believe?) the main difference is
> that Nick proposes a way to inject an exception into a generator; and
> I've said a few times that I like that idea.
>
> I'd like to propose to make that a separate PEP, which can combine
> elements of PEP 288 and PEP 325. Summary:
>
> - g.throw(type, value, traceback) causes the specified exception to be
> thrown at the place where the generator g is currently suspended. 
..
> - There's a new exception, GeneratorExit, which can be thrown to cause
> a generator to clean up. A generator should not yield a value in
> response to this exception.
>
> - g.close() throws a GeneratorExit exception in the generator, and
> catches it (so g.close() itself does not raise an exception).
> g.close() is idempotent -- if the generator is already closed, it is a
> no-op. If the generator, against the rules, yields another value, it
> is nevertheless marked closed.

+1

We're currently using python generators to handle concurrency in a single 
thread, and this allows a simple scheduler to have a clean way of sending 
generators a generator shutdown message. (Currently we have to do it
another way that is specific to the style of wrapped generator)

If you need a volunteer to code this - should it go through, I'm willing to 
have a go at this. (I can't do this though for 3 weeks or so though due to a 
crunch at work, and I might be in over my head in offering this.)


Michael.
-- 
Michael Sparks, Senior R&D Engineer, Digital Media Group
[EMAIL PROTECTED], http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail may contain personal views which are not the views of the BBC.
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Guido van Rossum]

[Phillip J. Eby]
> And there was much rejoicing in the land of the co-routiney people.  :)  
> +1000.
> 
> Should this maybe just be added to PEP 342?  To me, PEP 342 has always
> seemed incomplete without ways to throw() and close(), but that could
> easily be just me.  In any case I'd expect the implementation of
> 'next(arg)' to have some overlap with the implementation of 'throw()'.

Maybe, but on the other hand this idea can be done independently from
PEP 342. After the "monster-PEP" 340, I'd rather break proposals up in
small parts.

> Also, if the generator yields a value upon close(), shouldn't that throw a
> runtime error?  Otherwise, you have no way to know the generator's
> exception handling is broken.

Maybe. But then what should happen when this happens to close()
invoked by the GC? I guess the same as when a __del__() method raises
an exception -- print a traceback and go on. OK, works for me.

-- 
--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

Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 -Abstract Block Redux)

[Michael Chermside]

[I apologize in advance if this sounds a bit disjointed... I started
to argue one thing, but by the end had convinced myself of the
opposite, and I re-wrote the email to match my final conclusion.]

Guido writes:
> About deleting VAR I have mixed feelings. [...]
> I think that, given that we let the for-loop variable survive, we
> should treat the with-statement variable the same way.

We said the same thing about the variable in list comprehensions
and it's now obvious that it should NEVER have been allowed to escape
it's scope. But the key difference is that list comprehensions are
EXPRESSIONS, and for and 'with' are STATEMENTS. Expressions shouldn't
modify the local environment, statements often do.

Of course, that argument _permits_ not deleting VAR, but doesn't
recomend in favor of it.

My first thought for ideal behavior was that if VAR was previously
defined (eg: a global, an existing attribute of some object, etc),
then it should not be 'del''ed afterward. But VAR was newly created
by the 'with' statement then we WOULD del it to keep the namespace
"neat". Trouble is, that's FAR too complex, and depends on a
distinction Python has not used before (although it's nearly the
same as the property that controls the meaning of globally declared
variables).

My next thought was to just allow 'with' statements to introduce
their own "scope"... the meaning that the VAR variable takes on within
a 'with' statement is not propogated outside the scope of the statement.
But imagine trying to implement this in CPython... don't forget details
like supporting locals(). If it's too hard to do, then it's probably
not the right solution.

So then I thought "Well, what's the harm in letting the variable
survive the 'with' statement?" I'm a big fan of keeping namespaces
"clean", but it's just not important enough to incurr other penalties.
So in this case, I (reluctantly, after giving myself quite a talking-to)
favor having the 'with' statement with VAR create said variable in the
appropriate scope as a side-effect, much like 'for'.

-- Michael Chermside

___
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

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

[Michael Hudson]

Greg Ewing <[EMAIL PROTECTED]> writes:

> Guido van Rossum wrote:
>
>> PEP 340 is still my favorite, but it seems there's too much opposition
>> to it,
>
> I'm not opposed to PEP 340 in principle, but the
> ramifications seemed to be getting extraordinarily
> complicated, and it seems to be hamstrung by
> various backwards-compatibility constraints.
> E.g. it seems we can't make for-loops work the way
> they should in the face of generator finalisation
> or we break old code.

I think I zoned this part of the discussion out, but I've written code
like this:

lineiter = iter(aFile)

for line in lineiter:
if sectionmarker in line:
break
parseSection1Line(line)

for line in lineiter:
if sectionmarker in line:
break
parseSection2Line(line)

(though, not *quite* that regular...)

This is, to me, neat and clear.  I don't find the idea that iterators
are tied to exactly 1 for loop an improvement (even though they
usually will be).

Cheers,
mwh

-- 
   what's a web widget??
   thirmite: internet on a stick, on fire
   with web sauce!
-- from Twisted.Quotes
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby]

At 09:55 AM 5/18/2005 -0700, Guido van Rossum wrote:
>[Phillip J. Eby]
> > And there was much rejoicing in the land of the co-routiney 
> people.  :)  +1000.
> >
> > Should this maybe just be added to PEP 342?  To me, PEP 342 has always
> > seemed incomplete without ways to throw() and close(), but that could
> > easily be just me.  In any case I'd expect the implementation of
> > 'next(arg)' to have some overlap with the implementation of 'throw()'.
>
>Maybe, but on the other hand this idea can be done independently from
>PEP 342. After the "monster-PEP" 340, I'd rather break proposals up in
>small parts.

Okay.  Maybe we should just update PEP 325, then?  It has much of the stuff 
that we'd want in the new PEP, such as the rationale.  Your new proposal, 
AFAICT, is just a simple extension of the PEP 325 protocol (i.e., adding 
'throw()'), along with some decisions to resolve its open issues.  Even the 
addition of 'throw()' seems tacitly approved by this bit at the end:

"""Were PEP 288 implemented, Exceptions Semantics for close could be 
layered on top of it"""

So at this point it seems your proposal is just nailing down specifics for 
the open parts of PEP 325.

___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Guido van Rossum]

[Phillip J. Eby]
> Okay.  Maybe we should just update PEP 325, then?  It has much of the stuff
> that we'd want in the new PEP, such as the rationale.  Your new proposal,
> AFAICT, is just a simple extension of the PEP 325 protocol (i.e., adding
> 'throw()'), along with some decisions to resolve its open issues.  Even the
> addition of 'throw()' seems tacitly approved by this bit at the end:
> 
> """Were PEP 288 implemented, Exceptions Semantics for close could be
> layered on top of it"""
> 
> So at this point it seems your proposal is just nailing down specifics for
> the open parts of PEP 325.

Or PEP 288? That has throw() (albeit with a different signature). I
could do without the attributes though (PEP 342 provides a much better
solution IMO).

If either of those PEP authors feels like updating their PEP, they
have my blessings! I probably won't get to writing my own for a few
more days.

-- 
--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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

[Raymond Hettinger]

> I'd like to propose to make that a separate PEP, which can combine
> elements of PEP 288 and PEP 325. 

+1 
Overall, the combined PEP proposal looks pretty good.



> - g.throw(type, value, traceback) causes the specified exception to be
> thrown at the place where the generator g is currently suspended.

Are the value and traceback arguments optional as they are with the
current raise statement?  If they are optional, what would the default
be?  I think the preferred choice is to have the call to the throw
method be the anchor point.  That makes sense in a traceback so you can
see who threw the exception.

The alternative is to have the generator resumption point be the anchor.
That is closer to the notion that throw(ex) is equivalent to a "raise
ex" following the last yield.   This probably isn't the way to go but
the PEP should address it explicitly.



> If the generator raises another exception (this includes
> the StopIteration produced when it returns) that exception is raised
> by the throw. In summary, throw() behaves like next() except it raises
> an exception at the place of the yield.

The parallel to next() makes this easy to understand, learn, and
implement.  However, there are some disadvantages to passing through a
StopIteration.  It means that throw() calls usually need to be wrapped
in a try/except or that a generator's exception handler would terminate
with a "yield None" where a "return" would be more natural.  As a
example, it is a bit painful to simulate the effects of g.close() using
g.throw(GeneratorExit).




> That's it! With this, we can write the decorator from Nick's PEP 3XX
> and the generator examples in PEP 343 can be rewritten to have a
> try/finally clause around the yield statement.

Yea!  This is very nice.


 
> Oh, somewhere it should be stated that yield without an expression is
> equivalent to yield None. PEP 342 ("continue EXPR") already implies
> that, so we don't have to write a separate PEP for it.

Right.



> I also propose
> to go with the alternative in PEP 342 of using next() rather than
> __next__() -- generators will have methods next(), throw(), and
> close().

+0  The switch from __next__() to next() is attractive but not essential
to the proposal.  Besides a small cost to backwards compatability, it
introduces yet another new/old style distinction where we have to keep
both forms in perpetuity.



Raymond
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

[Raymond Hettinger]

> > Should this maybe just be added to PEP 342?  To me, PEP 342 has
always
> > seemed incomplete without ways to throw() and close(), but that
could
> > easily be just me.  In any case I'd expect the implementation of
> > 'next(arg)' to have some overlap with the implementation of
'throw()'.
> 
> Maybe, but on the other hand this idea can be done independently from
> PEP 342. After the "monster-PEP" 340, I'd rather break proposals up in
> small parts.

+1

I want this as a separate PEP.  It is a straight-forward solution to
long standing issues.  I would rather not have it contaminated with
distracting issues and co-routine dreams.


Raymond
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Raymond Hettinger]

> Okay.  Maybe we should just update PEP 325, then?

-1.

Keep this separate.


Raymond
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

[Guido van Rossum]

[Raymond Hettinger]
> Are the value and traceback arguments optional as they are with the
> current raise statement?  If they are optional, what would the default
> be?  I think the preferred choice is to have the call to the throw
> method be the anchor point.  That makes sense in a traceback so you can
> see who threw the exception.

AFAI throw() is concerned, the defaults are None. The raise statement
does something sane when the second and/or third arg are None (the
first can't be though).

> The alternative is to have the generator resumption point be the anchor.
> That is closer to the notion that throw(ex) is equivalent to a "raise
> ex" following the last yield.   This probably isn't the way to go but
> the PEP should address it explicitly.

It's actually kind of tricky since the exception will come *back* to
the throw point anyway. I think the traceback ought to start at the
resumption point by default.

> > If the generator raises another exception (this includes
> > the StopIteration produced when it returns) that exception is raised
> > by the throw. In summary, throw() behaves like next() except it raises
> > an exception at the place of the yield.
> 
> The parallel to next() makes this easy to understand, learn, and
> implement.  However, there are some disadvantages to passing through a
> StopIteration.  It means that throw() calls usually need to be wrapped
> in a try/except or that a generator's exception handler would terminate
> with a "yield None" where a "return" would be more natural.  As a
> example, it is a bit painful to simulate the effects of g.close() using
> g.throw(GeneratorExit).

Doesn't bother me; the main use case is in the do_template (or
with_template) decorator. Since it must support both raising an
exception and returning a value, we're pretty much forced to catch the
exception (unless we just want to pass it through, which is actually a
reasonable use case).

> > I also propose
> > to go with the alternative in PEP 342 of using next() rather than
> > __next__() -- generators will have methods next(), throw(), and
> > close().
> 
> +0  The switch from __next__() to next() is attractive but not essential
> to the proposal.  Besides a small cost to backwards compatability, it
> introduces yet another new/old style distinction where we have to keep
> both forms in perpetuity.

Right. PBP. :-)

-- 
--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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

[Raymond Hettinger]

> [Raymond Hettinger]
> > Are the value and traceback arguments optional as they are with the
> > current raise statement?  If they are optional, what would the
default
> > be?  I think the preferred choice is to have the call to the throw
> > method be the anchor point.  That makes sense in a traceback so you
can
> > see who threw the exception.
> 
> AFAI throw() is concerned, the defaults are None. The raise statement
> does something sane when the second and/or third arg are None (the
> first can't be though).
> 
> > The alternative is to have the generator resumption point be the
anchor.
> > That is closer to the notion that throw(ex) is equivalent to a
"raise
> > ex" following the last yield.   This probably isn't the way to go
but
> > the PEP should address it explicitly.
> 
> It's actually kind of tricky since the exception will come *back* to
> the throw point anyway. I think the traceback ought to start at the
> resumption point by default.
> 
> > > If the generator raises another exception (this includes
> > > the StopIteration produced when it returns) that exception is
raised
> > > by the throw. In summary, throw() behaves like next() except it
raises
> > > an exception at the place of the yield.
> >
> > The parallel to next() makes this easy to understand, learn, and
> > implement.  However, there are some disadvantages to passing through
a
> > StopIteration.  It means that throw() calls usually need to be
wrapped
> > in a try/except or that a generator's exception handler would
terminate
> > with a "yield None" where a "return" would be more natural.  As a
> > example, it is a bit painful to simulate the effects of g.close()
using
> > g.throw(GeneratorExit).
> 
> Doesn't bother me; the main use case is in the do_template (or
> with_template) decorator. Since it must support both raising an
> exception and returning a value, we're pretty much forced to catch the
> exception (unless we just want to pass it through, which is actually a
> reasonable use case).
> 
> > > I also propose
> > > to go with the alternative in PEP 342 of using next() rather than
> > > __next__() -- generators will have methods next(), throw(), and
> > > close().
> >
> > +0  The switch from __next__() to next() is attractive but not
essential
> > to the proposal.  Besides a small cost to backwards compatability,
it
> > introduces yet another new/old style distinction where we have to
keep
> > both forms in perpetuity.
> 
> Right. PBP. :-)


FWIW, I'm in agreement with everything.
I hope this one gets accepted.
Please do put it in a separate PEP.


Raymond
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

[Phillip J. Eby]

At 01:24 PM 5/18/2005 -0400, Raymond Hettinger wrote:
> > - g.throw(type, value, traceback) causes the specified exception to be
> > thrown at the place where the generator g is currently suspended.
>
>Are the value and traceback arguments optional as they are with the
>current raise statement?  If they are optional, what would the default
>be?  I think the preferred choice is to have the call to the throw
>method be the anchor point.  That makes sense in a traceback so you can
>see who threw the exception.
>
>The alternative is to have the generator resumption point be the anchor.
>That is closer to the notion that throw(ex) is equivalent to a "raise
>ex" following the last yield.   This probably isn't the way to go but
>the PEP should address it explicitly.

My use case for throw() calls for the latter option; i.e., the exception is 
raised by the yield expression at the resumption point.  Keep in mind that 
if the exception passes out of the generator, the throw() call will show in 
the traceback anyway.  It's unlikely the generator itself will inspect the 
traceback and need to see the throw() call as if it were nested.


> > If the generator raises another exception (this includes
> > the StopIteration produced when it returns) that exception is raised
> > by the throw. In summary, throw() behaves like next() except it raises
> > an exception at the place of the yield.
>
>The parallel to next() makes this easy to understand, learn, and
>implement.  However, there are some disadvantages to passing through a
>StopIteration.  It means that throw() calls usually need to be wrapped
>in a try/except or that a generator's exception handler would terminate
>with a "yield None" where a "return" would be more natural.  As a
>example, it is a bit painful to simulate the effects of g.close() using
>g.throw(GeneratorExit).

I don't see this as a big problem, personally, but that's because all of my 
use cases for throw() will be using only one piece of code that calls 
throw(), and that code will be overall simplified by the availability of 
throw().

It's also easy to write a wrapper for control-flow "signals" of the kind 
you used in PEP 288:

 def send(gen, *exc):
 try:
 return gen.throw(*exc)
 except StopIteration:
 pass

___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Phillip J. Eby]

At 01:28 PM 5/18/2005 -0400, Raymond Hettinger wrote:
> > Okay.  Maybe we should just update PEP 325, then?
>
>-1.
>
>Keep this separate.

Have you read PEP 325 lately?  Mostly the change would consist of deleting 
rejected options or moving them to a rejected options section.  The only 
other change would be adding a short section stating how throw() would work 
and that it's being made public to support the future use of generators as 
flow-control templates.

A new PEP would have to copy, reinvent, or reference large chunks of PEP 
325, resulting in either redundancy or excess complexity.

Or are you suggesting a new PEP for throw(), containing *only* an 
explanation of its semantics, and then modifying PEP 325 to indicate that 
it will be implemented using the new PEP's 'throw()'?  That's about the 
only scenario that makes sense to me for adding a new PEP, because PEP 325 
is already pretty darn complete with respect to close() and GC.

___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325:generator exceptions and cleanup

[Raymond Hettinger]

> > So at this point it seems your proposal is just nailing down
specifics
> for
> > the open parts of PEP 325.
> 
> Or PEP 288? That has throw() (albeit with a different signature). I
> could do without the attributes though (PEP 342 provides a much better
> solution IMO).
> 
> If either of those PEP authors feels like updating their PEP, they
> have my blessings! I probably won't get to writing my own for a few
> more days.

Okay, I volunteer to recast PEP 288 to encompass your combined proposal.

Will tackle it in the morning.


Raymond
___
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

Re: [Python-Dev] Simpler finalization semantics (was Re: PEP 343 - Abstract Block Redux)

[Michael Chermside]

Guido writes:

  [a rather silly objection to Phillip's proposal that 'with x:' is
   a no-op when x lacks __enter__ and __exit__]

> I know this is not a very strong argument, but my gut tells me this
> generalization of the with-statement is wrong, so I'll stick to it
> regardless of the strength of the argument. The real reason will come
> to me.

Perhaps the real reason is that it allows errors to pass silently.

If I write

with foo:
   BLOCK

where I should have written

with locked(foo):
   BLOCK

...it silently "succeeds" by doing nothing. I CLEARLY intended to
do the appropriate cleanup (or locking, or whatever), but it doesn't
happen.

-- Michael Chermside

___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[David Goodger]

[Guido van Rossum]
> I believe that in the discussion about PEP 343 vs. Nick's PEP 3XX
> (http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html, still
> awaiting PEP moderator approval I believe?) ...

Nick hasn't submitted it for a PEP number yet.

--
David Goodger 


signature.asc
Description: OpenPGP digital signature
___
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

[Python-Dev] Adding content to exception messages

[Nicolas Fleury]

Sorry if this message is not a direct reply to Ka-Ping
Yee message on PEP344, I'm in vacation in China and
there's a thing I must say that could make sense in
PEP344. 

I do a lot of exception re-raising at work; I use that
technique to add content to exception messages while
keeping the original stack.  I even created a reraise
function that I use that way:

try:
parser.parseFile(file)
exeption Exception, exception:
reraise(exception, 
"Error at line %s in file %s" % (x,y))

(x,y) are details, but you get the idea.

This very useful in many situations.  In the example,
it works when an error is happening in parsing a file
including other files (like xml files with
).  That way you get the exact path of
inclusion leading to the error.  It is also useful
when an error happen in very generic code and when
traceback is not enough to know which element was
causing the error.

What I propose is that all exceptions objects have a
standard way to add additional informations. 
Something like:

try: 
foo()
except Exception, exception:
exception.add_info("some info")
raise exception from (whatever the proposition is)

You might ask, "why not just reraise a new
exception?".  It is more useful to reraise the same
exception type, making it possible to use selective
except clauses and (avoid problems with code using
them like hasattr).  I think what would be simpler is
not affect __str__ representation and prepend to a
list the additional infos inside the exception object,
adding a function to get these infos.  I don't mind
how it would be done in fact, as long as the need is
fulfilled.  I won't be able to read my messages often
for the next 10 days, but I hope others will see the
point I try to bring;)

Regards,
Nicolas




Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generatorexceptions and cleanup

[Greg Ewing]

Phillip J. Eby wrote:
> My use case for throw() calls for the latter option; i.e., the exception is 
> raised by the yield expression at the resumption point.  Keep in mind that 
> if the exception passes out of the generator, the throw() call will show in 
> the traceback anyway.  It's unlikely the generator itself will inspect the 
> traceback and need to see the throw() call as if it were nested.

There mightn't be much choice anyway. If the frame making
the call to throw() were to be made the starting point for
the traceback, and the exception propagated back to the
throw, something would try to put the same frame in the
traceback twice, which can't work since it's a linked
list.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

Re: [Python-Dev] PEP 343 - New kind of yield statement?

[Greg Ewing]

Michael Hudson wrote:

> This is, to me, neat and clear.  I don't find the idea that iterators
> are tied to exactly 1 for loop an improvement (even though they
> usually will be).

To fix this in a fully backward-compatible way, we
need some way of distinguishing generators that
expect to be finalized.

Suppose we leave the 'yield' statement alone, and
introduce a new statement 'suspend', which alone
has the new capabilities of

(1) allowing injection of exceptions
(2) ability to return a value
(3) permissibility in a try-finally

Doing throw() on a generator that is stopped at
a yield statement would simply raise the exception
without changing the state of the generator. So
the for-loop could be made to finalize by default,
and existing generators would be unaffected.

A with-statement generator would then look like

   @with_template
   def foo():
 initialize()
 try:
   suspend
 finally:
   finalize()

which I think looks quite nice, because 'suspend'
seems more suggestive of what is happening when
you're not yielding a value. The same thing applies
to coroutine-type applications.

For partial iteration of new-style generators,
there could be a new statement

   for var from expr:
 ...

or maybe just a wrapper function

   for var in partial(expr):
 ...

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

Re: [Python-Dev] PEP 344: Exception Chaining and Embedded Tracebacks

[Greg Ewing]

Guido van Rossum wrote:
> Here's another rule-of-thumb: when the VM and the user *share* the
> attribute space of an object, the VM uses system attributes; the VM
> uses plain attributes for objects that it owns completely (like code
> objects, frames and so on, which rarely figure user code except for
> the explicit purpose of introspection). So I think the PEP should
> continue to use __traceback__ etc.

I was just thinking the same thing myself!

(Does Guido have a telepathy machine now, as well
as a time machine?)

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

Re: [Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Greg Ewing]

Guido van Rossum wrote:

> - When a generator is GC'ed, its close() method is called (which is a
> no-op if it is already closed).

Does this mean that all generators will be ineligible
for cyclic garbage collection (since they implicitly
have something equivalent to a __del__ method)?

Other than that, all this looks good.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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