Mailman 3 May 2005 - Python-Dev

Pre-PEP: Unifying try-except and try-finally
by Jim Jewett May 12, 2005

May 12, 2005

[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 you asked permission it seemed somehow serious and permanent. By itself, the change is fine -- but there is still a nagging worry that it might interact badly with PEP-340 (or 3XX) Resource Management blocks. (1) If people could write a single try statement instead of nesting them, would they be less likely to factor the locking out into a separate statement? (2) If 340 ends up as a simple version that doesn't handle fancy except: processing, would this change make PEP 340 look crippled in comparison? Would people avoid Resource Managers as a matter of style? -jJ

1 0

Merging PEP 310 and PEP 340-redux?
by Jim Jewett May 12, 2005

May 12, 2005

In http://mail.python.org/pipermail/python-dev/2005-May/053652.html Nick wrote: terminate = True VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause try: try: BLOCK1 except TerminateBlock: raise # Disallow suppression of TerminateBlock except: terminate = False if not stmt_exit(*sys.exc_info()): raise else: terminate = False stmt_exit() finally: if terminate: try: stmt_exit(TerminateBlock, None, None) except TerminateBlock: pass This seems confusing to me, as if it were saying "OK, I don't want to finalize this, so I'll set terminate to false, but then finalize anyhow." Would "terminated=False" (and getting set later to True) still meet your requirements? Or even "finalized=False"? I realize that the spelling of finalise is a bugaboo, but presumably this is really a hidden variable, instead of something that the user must type. Or have I misunderstood that as well? -jJ

1 0

Pre-PEP: Unifying try-except and try-finally
by Reinhold Birkenfeld May 12, 2005

May 12, 2005

Hello, after proposing this here (albeit deep in the PEP 340 thread) and getting a somewhat affirmatory response from Guido, I have written something that could become a PEP if sufficiently hatched... --------------------------- PEP: XXX Title: Unifying try-except and try-finally Version: $Revision: $ Last-Modified: $Date: $ Author: Reinhold Birkenfeld <reinhold-birkenfeld-nospam(a)wolke7.net> Status: Draft Type: Standards Track Content-Type: text/plain Created: 04-May-2005 Post-History: Abstract This PEP proposes a change in the syntax and semantics of try statements to allow combined try-except-finally blocks. This means in short that it would be valid to write try: <do something> except Exception: <handle the error> finally: <cleanup> Rationale/Proposal There are many use cases for the try-except statement and for the try-finally statement per se; however, often one needs to catch exceptions and execute some cleanup code afterwards. It is slightly annoying and not very intelligible that one has to write f = None try: try: f = open(filename) text = f.read() except IOError: print 'An error occured' finally: if f: f.close() So it is proposed that a construction like this try: <suite 1> except Ex1: <suite 2> <more except: clauses> else: <suite 3> finally: <suite 4> be exactly the same as the legacy try: try: <suite 1> except Ex1: <suite 2> <more except: clauses> else: <suite 3> finally: <suite 4> This is backwards compatible, and every try statement that is legal today would continue to work. Changes to the grammar The grammar for the try statement, which is currently try_stmt: ('try' ':' suite (except_clause ':' suite)+ ['else' ':' suite] | 'try' ':' suite 'finally' ':' suite) would have to become try_stmt: ('try' ':' suite (except_clause ':' suite)+ ['else' ':' suite] ['finally' ':' suite] | 'try' ':' suite (except_clause ':' suite)* ['else' ':' suite] 'finally' ':' suite) Implementation As the PEP author currently does not have sufficient knowledge of the CPython implementation, he is unfortunately not able to deliver one. References None yet. Copyright This document has been placed in the public domain. ----------------------- Reinhold -- Mail address is perfectly valid!

17 38

PEP 340: Breaking out.
by Tom Rothamel May 11, 2005

May 11, 2005

I have a question/suggestion about PEP 340. As I read the PEP right now, the code: while True: block synchronized(v1): if v1.field: break time.sleep(1) Will never break out of the enclosing while loop. This is because the break breaks the while loop that the block statement is translated into, instead of breaking the outer True statement. Am I understanding this right, or am I misunderstanding this? If I am understanding this right, I would suggest allowing some way of having the iterator call continue or break in the enclosing context. (Perhaps by enclosing the entire translation of block in a try-except construct, which catches Stop and Continue exceptions raised by the generator and re-raises them in the outer context.) I hope this helps. -- Tom Rothamel ----------------------------------- http://www.rothamel.us/~tom/

27 56

Python 2.4 set objects and cyclic garbage
by Barry Warsaw May 11, 2005

May 11, 2005

In setobject.c rev 1.26 + 1.27 Raymond removed gc support from built-in set objects, claiming in the log message that "sets cannot have cycles". Yet the attached program creates a cycle that I don't believe ever gets reclaimed. Patch 1200018 restores GC support to set objects for Python 2.4. Thanks to my colleague Matt Messier for finding this. kick-me-if-i'm-smoking-something-ly y'rs, -Barry http://sourceforge.net/tracker/index.php?func=detail&aid=1200018&group_id=5…

1 0

CHANGE BayPIGgies: May *THIRD* Thurs
by Aahz May 11, 2005

May 11, 2005

Reminder: We will *NOT* be meeting the *SECOND* Thursday (this week, May 12). Our May meeting will be the *THIRD* Thursday, May 19. This will be our first meeting at Google, with Alex Martelli's presention on design patterns. More details soon! -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "And if that makes me an elitist...I couldn't be happier." --JMS

1 0

Re: Kernel panic writing to /dev/dsp with cmpci driver
by duraivel May 11, 2005

May 11, 2005

thanx and regards duraivel

1 0

Python continually calling sigprocmask() on FreeBSD 5
by Suleiman Souhlal May 11, 2005

May 11, 2005

Hello, While investigating why the script used in http://docs.freebsd.org/ cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much system time on FreeBSD 5, I noticed that python is continually calling sigprocmask(), as can be seen from the following ktrace(1) dump: 673 python 0.000007 CALL sigprocmask(0x3,0,0x811d11c) 673 python 0.000005 RET sigprocmask 0 673 python 0.000009 CALL sigprocmask(0x1,0,0x8113d1c) 673 python 0.000005 RET sigprocmask 0 etc.. This is using Python 2.4.1. Any clue about why this is happening? (Please include me to the recipients for any reply, as I'm not subscribed) Bye, -- Suleiman Souhlal | ssouhlal(a)vt.edu The FreeBSD Project | ssouhlal(a)FreeBSD.org

3 2

Re: [Python-Dev] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
by Delaney, Timothy C (Timothy) May 11, 2005

May 11, 2005

Greg Ewing wrote: > Nick Coghlan wrote: >> Hmm, with that approach, a code inspection tool like pychecker could >> be used to pick up the slack, and flag generators which have a yield >> inside a try/finally or a user defined statement without applying >> the "needs finalisation" decorator > > What about giving them an __exit__ method if and only > if they have a yield inside a try/finally? Old generators > won't be doing that, because it's currently illegal. It's possible to create a generator that does not contain a finally, but still needs cleanup. def gen(): try: yield except: print 'cleanup' raise Tim Delaney

1 0

PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
by Nick Coghlan May 11, 2005

May 11, 2005

PEP 340 contains several different ideas. This rewrite separates them into five major areas: - passing data into an iterator - finalising iterators - integrating finalisation into for loops - the new non-looping finalising statement - integrating all of these with generators. The first area has nothing to do with finalisation, so it is not included in this rewrite (Steven Bethard wrote an Enhanced Iterators pre-PEP which covers only that area, though). The whole PEP draft can be found here: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html But I've inlined some examples that differ from or aren't in PEP 340 for those that don't have time to read the whole thing (example numbers are from the PEP): 4. A template that tries something up to n times:: def auto_retry(n=3, exc=Exception): for i in range(n): try: yield except exc, err: # perhaps log exception here yield raise # re-raise the exception we caught earlier Used as follows:: for del auto_retry(3, IOError): f = urllib.urlopen("http://python.org/") print f.read() 6. It is easy to write a regular class with the semantics of example 1:: class locking: def __init__(self, lock): self.lock = lock def __enter__(self): self.lock.acquire() def __exit__(self, type, value=None, traceback=None): self.lock.release() if type is not None: raise type, value, traceback (This example is easily modified to implement the other examples; it shows that generators are not always the simplest way to do things.) 8. Find the first file with a specific header:: for name in filenames: stmt opening(name) as f: if f.read(2) == 0xFEB0: break 9. Find the first item you can handle, holding a lock for the entire loop, or just for each iteration:: stmt locking(lock): for item in items: if handle(item): break for item in items: stmt locking(lock): if handle(item): break 10. Hold a lock while inside a generator, but release it when returning control to the outer scope:: stmt locking(lock): for item in items: stmt unlocking(lock): yield item Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

9 41