logo       

[ jython-Patches-868514 ] yield in finally block -- yield in nested try:exc: msg#00021

lang.jython.devel

Subject: [ jython-Patches-868514 ] yield in finally block -- yield in nested try:except:

Patches item #868514, was opened at 2003-12-31 12:03
Message generated for change (Comment added) made by lycotic
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=312867&aid=868514&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Brown (lycotic)
Assigned to: Nobody/Anonymous (nobody)
>Summary: yield in finally block -- yield in nested try:except:

Initial Comment:
Following the advice of Samuele Pedroni (message to
python-dev of 2002-10-17 -- a while ago), reworked the way
yields and f_lasti are implemented to work with finally
blocks. Then spent a while arguing with the verifier.

The second file is some test cases I found useful;
test_generators in the CPython standard lib doesn't exercise
yields in finallys all that much.

----------------------------------------------------------------------

>Comment By: Randy Brown (lycotic)
Date: 2004-01-10 13:31

Message:
Logged In: YES
user_id=920303

The python std. library dir *.class gives

3678583 bytes before

and

3681995 bytes after inlining finallys

I'm guessing that nested finallys aren't all that common.

I'm sure you could easily contrive an example that blows up;
but I don't think that kind of thing is all that common.
All in all, I'm happier with the newer patch, especially
some regularization of how it treats try:except: and
try:finally:; although the techniques of the two patches
could be merged somewhat.

----------------------------------------------------------------------

Comment By: Randy Brown (lycotic)
Date: 2004-01-10 13:10

Message:
Logged In: YES
user_id=920303

Attached a patch that inlines the finally blocks.

It turns out that some of the verifier problems I was having
with try:finally: happen to try:except: as well (nothing to
do with jsrs -- just that the restoreLocals code shouldn't
really be in any exception ranges). This patch, thus,
covers more cases than the previous one, because it handles
try:except: as well.

Added a test in test_jy_generators that tests a failing
try:except: case.

I'm looking into what this does to code size; more later.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2004-01-05 13:54

Message:
Logged In: YES
user_id=61408

oops, forgot to login, that was me

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-01-05 13:46

Message:
Logged In: NO

ah, well it seems that sun cannot make up its mind

http://developer.java.sun.com/developer/bugParade/bugs/4739388.html

they have added a flag to get jsrs back.

pro to no jsrs:
- it simplifies the compiler code
- verification of jsr is one of the most delicate part of
bytecode
verif.
- speed, although reentering a generator in a finally clause
and yield in finally clauses are rather untypical

contra:
- code could blow up, deeply nested try-finally are not that
typical in Python but we emit more bytecode per line of code,
and if PEP 310 is accepted nesting try-finally will be even
easier, more common?

Having some measure about what kind of code lengths we could
get both ways would be good.






----------------------------------------------------------------------

Comment By: Randy Brown (lycotic)
Date: 2004-01-05 13:16

Message:
Logged In: YES
user_id=920303

True, but I don't regret the learning experience. As I said
on the other patch, I think that inlining finallys won't be
so bad, especially with generators, so long as there aren't
too many exits from the try block and the finallys aren't
nested.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2004-01-04 22:05

Message:
Logged In: YES
user_id=61408

oops, I didn't notice this patch [SF btw sofar didn't sent
any notification mail about these patches, strange.]

this is very good, but as I have written commenting another
patch sun switched away from jsr. At some point it would be
good to do the same. Not that this mean that this will not
go in , pending review.

There is a lesson still, it is a good idea before writing
any patch that is not trivial to ping jython-dev. I knew
since some time about sun change of strategy.

Thanks for the work.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=312867&aid=868514&group_id=12867


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise