Re: try/except/finally

2014-06-11 Thread Roy Smith
In article , alister wrote: > On Wed, 11 Jun 2014 00:00:49 +, Steven D'Aprano wrote: > > > On Wed, 11 Jun 2014 06:37:01 +1000, Chris Angelico wrote: > > > >> I don't know a single piece of programming advice which, if taken as an > >> inviolate rule, doesn't at some point cause suboptimal

Re: try/except/finally

2014-06-11 Thread alister
On Wed, 11 Jun 2014 00:00:49 +, Steven D'Aprano wrote: > On Wed, 11 Jun 2014 06:37:01 +1000, Chris Angelico wrote: > >> I don't know a single piece of programming advice which, if taken as an >> inviolate rule, doesn't at some point cause suboptimal code. > > "Don't try to program while your

Re: try/except/finally

2014-06-10 Thread Rustom Mody
On Tuesday, June 10, 2014 11:41:45 PM UTC+5:30, Skip Montanaro wrote: > Would be interesting to get their collective take on C++... > Are there any good parts? It appears the book was cancelled > https://www.matthewsbooks.com/productdetail.aspx?productid=4493SAT1969&returnurl=%2Fforthcomingtitles

Re: try/except/finally

2014-06-10 Thread Mark Lawrence
On 11/06/2014 02:00, Chris Angelico wrote: On Wed, Jun 11, 2014 at 10:53 AM, Mark Lawrence wrote: Does it make any difference if the cat is European or African? What? I don't know. ARGH! ChrisA Awfully sorry, it's 2 a.m. here, next time I'll try to remember

Re: try/except/finally

2014-06-10 Thread Chris Angelico
On Wed, Jun 11, 2014 at 10:53 AM, Mark Lawrence wrote: > Does it make any difference if the cat is European or African? What? I don't know. ARGH! ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: try/except/finally

2014-06-10 Thread Mark Lawrence
On 11/06/2014 01:40, Tim Delaney wrote: On 11 June 2014 10:00, Steven D'Aprano mailto:steve+comp.lang.pyt...@pearwood.info>> wrote: On Wed, 11 Jun 2014 06:37:01 +1000, Chris Angelico wrote: > I don't know > a single piece of programming advice which, if taken as an inviolate

Re: try/except/finally

2014-06-10 Thread Tim Delaney
On 11 June 2014 10:00, Steven D'Aprano wrote: > On Wed, 11 Jun 2014 06:37:01 +1000, Chris Angelico wrote: > > > I don't know > > a single piece of programming advice which, if taken as an inviolate > > rule, doesn't at some point cause suboptimal code. > > "Don't try to program while your cat is

Re: try/except/finally

2014-06-10 Thread Roy Smith
> On Wed, Jun 11, 2014 at 10:00 AM, Steven D'Aprano > wrote: > > "Don't try to program while your cat is sleeping on the keyboard." In article , Chris Angelico wrote: > Hmm. I've never actually heard that one. Is it commonly taught in > programming classes? Because I haven't taken any. A pictu

Re: try/except/finally

2014-06-10 Thread Chris Angelico
On Wed, Jun 11, 2014 at 10:00 AM, Steven D'Aprano wrote: > On Wed, 11 Jun 2014 06:37:01 +1000, Chris Angelico wrote: > >> I don't know >> a single piece of programming advice which, if taken as an inviolate >> rule, doesn't at some point cause suboptimal code. > > "Don't try to program while your

Re: try/except/finally

2014-06-10 Thread Steven D'Aprano
On Wed, 11 Jun 2014 06:37:01 +1000, Chris Angelico wrote: > I don't know > a single piece of programming advice which, if taken as an inviolate > rule, doesn't at some point cause suboptimal code. "Don't try to program while your cat is sleeping on the keyboard." -- Steven D'Aprano http://imp

Re: try/except/finally

2014-06-10 Thread Mark Lawrence
On 10/06/2014 21:43, Ethan Furman wrote: On 06/10/2014 01:38 PM, Roy Smith wrote: Chris Angelico wrote: # Yeah. As soon as you take on board a hard-and-fast rule, you open yourself up to stupid cases where the rule ought to have been broken. I don't know a single piece of programming advice wh

Re: try/except/finally

2014-06-10 Thread Ethan Furman
On 06/10/2014 01:38 PM, Roy Smith wrote: Chris Angelico wrote: # Yeah. As soon as you take on board a hard-and-fast rule, you open yourself up to stupid cases where the rule ought to have been broken. I don't know a single piece of programming advice which, if taken as an inviolate rule, doesn'

Re: try/except/finally

2014-06-10 Thread Chris Angelico
On Wed, Jun 11, 2014 at 6:38 AM, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> Yeah. As soon as you take on board a hard-and-fast rule, you open >> yourself up to stupid cases where the rule ought to have been broken. >> I don't know a single piece of programming advice which, if

Re: try/except/finally

2014-06-10 Thread Roy Smith
In article , Chris Angelico wrote: > Yeah. As soon as you take on board a hard-and-fast rule, you open > yourself up to stupid cases where the rule ought to have been broken. > I don't know a single piece of programming advice which, if taken as > an inviolate rule, doesn't at some point cause s

Re: try/except/finally

2014-06-10 Thread Chris Angelico
On Wed, Jun 11, 2014 at 4:48 AM, Grant Edwards wrote: > I've seen some amazingly convoluted C code where people got themselves > wrapped around the axle six different ways in order to avoid using > "goto fail" or "goto retry". Invariably I was looking at the code > because it didn't work right an

Re: try/except/finally

2014-06-10 Thread alister
On Tue, 10 Jun 2014 19:14:18 +0100, Mark Lawrence wrote: > On 10/06/2014 08:27, Thomas Rachel wrote: >> Am 08.06.2014 05:58 schrieb Rustom Mody: >> >>> Some people¹ think that gotos are a code-smell. >>> ¹ I am not exactly those people. >>> A chap called E W Dijkstra made the statement: "Goto sta

Re: try/except/finally

2014-06-10 Thread Grant Edwards
On 2014-06-10, Mark Lawrence wrote: > I entirely agree. I find it incredible that some people find it so > difficult to differentiate having tens or even hundreds of gotos > leaping around willy nilly to a similar number of labels, and a > similar number of gotos targetted at one label called S

Re: try/except/finally

2014-06-10 Thread Mark Lawrence
On 10/06/2014 08:27, Thomas Rachel wrote: Am 08.06.2014 05:58 schrieb Rustom Mody: Some people¹ think that gotos are a code-smell. ¹ I am not exactly those people. A chap called E W Dijkstra made the statement: "Goto statement considered harmful" and became famous. And became widely misunder

Re: try/except/finally

2014-06-10 Thread Skip Montanaro
> Here is Dijkstra: > http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html ... > And here is Hoare... > | Ada has a plethora of features and notational conventions, many of them > | unnecessary and some of them, like exception handling, even > | dangerous. Do not

Re: try/except/finally

2014-06-10 Thread Rustom Mody
On Tuesday, June 10, 2014 12:57:29 PM UTC+5:30, Thomas Rachel wrote: > Am 08.06.2014 05:58 schrieb Rustom Mody: > > Some people� think that gotos are a code-smell. > > � I am not exactly those people. > > A chap called E W Dijkstra made the statement: "Goto statement considered > > harmful" and b

Re: try/except/finally

2014-06-10 Thread Marko Rauhamaa
Thomas Rachel : > Essentially, you can write both good and bad code both with and > without goto. Point is, choose tasteful idioms in your code. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: try/except/finally

2014-06-10 Thread Thomas Rachel
Am 08.06.2014 05:58 schrieb Rustom Mody: Some people¹ think that gotos are a code-smell. ¹ I am not exactly those people. A chap called E W Dijkstra made the statement: "Goto statement considered harmful" and became famous. And became widely misunderstood. If anybody would read the whole what

Re: try/except/finally

2014-06-09 Thread Skip Montanaro
On Mon, Jun 9, 2014 at 11:23 AM, Shiyao Ma wrote: > > It would be great if someone could discuss it from the viewpoint of bytecode. > e.g., how the stack is popped, etc. BITD, you couldn't have try/except/finally. You could have try/except or try/finally. You could nest the two,

Re: try/except/finally

2014-06-09 Thread Shiyao Ma
It would be great if someone could discuss it from the viewpoint of bytecode. e.g., how the stack is popped, etc. 2014-06-09 17:40 GMT+08:00 Marko Rauhamaa : > Philip Shaw : > > > OTOH, it could just be that Guido didn't think of banning [return from > > finally] when exceptions were first added

Re: try/except/finally

2014-06-09 Thread Marko Rauhamaa
Philip Shaw : > OTOH, it could just be that Guido didn't think of banning [return from > finally] when exceptions were first added and doesn't want to > introduce an incompatability later. You don't have to ban all nonsensical things. Most guns allow you to shoot yourself in the foot, even those

Re: try/except/finally

2014-06-09 Thread Philip Shaw
On 2014-06-08, Dave Angel wrote: > Frank B Wrote in message: >> Ok; this is a bit esoteric. >> >> So finally is executed regardless of whether an exception occurs, so states >> the docs. >> >> But, I thought, if I from my function first, that should take >> precedence. >> >> au contraire >>

Re: try/except/finally

2014-06-08 Thread Ian Kelly
On Sun, Jun 8, 2014 at 11:57 AM, Joshua Landau wrote: > On 8 June 2014 08:12, Marko Rauhamaa wrote: >> >> Does anyone have an example motivating a return from finally? It seems >> to me it would always be a bad idea as it silently clears all unexpected >> exceptions. > > In a general sense: > >

Re: try/except/finally

2014-06-08 Thread Ian Kelly
On Sun, Jun 8, 2014 at 12:02 PM, Ian Kelly wrote: > On Sun, Jun 8, 2014 at 11:57 AM, Joshua Landau wrote: >> On 8 June 2014 08:12, Marko Rauhamaa wrote: >>> >>> Does anyone have an example motivating a return from finally? It seems >>> to me it would always be a bad idea as it silently clears al

Re: try/except/finally

2014-06-08 Thread Joshua Landau
On 6 June 2014 18:39, Roy Smith wrote: > > The only way I can think of to bypass a finally block would be to call > os._exit(), or send yourself a kill signal. If you're willing to use implementation details... --- # BreakN.py import sys # Turn tracing on if it is off if sys.gettrace() is Non

Re: try/except/finally

2014-06-08 Thread Joshua Landau
On 8 June 2014 08:12, Marko Rauhamaa wrote: > > Does anyone have an example motivating a return from finally? It seems > to me it would always be a bad idea as it silently clears all unexpected > exceptions. In a general sense: try: something_that_can_break() return foo() # b

Re: try/except/finally

2014-06-08 Thread Marko Rauhamaa
Mark Lawrence : >>> A return statement inside a finally block is code smell. >> Not to my nose. It seems like a perfectly reasonable thing to do. > I agree, the code smell is the return in the except block. Here's a regular pattern that I use for nonblocking I/O: def poll(self): try

Re: try/except/finally

2014-06-07 Thread Rustom Mody
On Sunday, June 8, 2014 5:17:21 AM UTC+5:30, Chris Angelico wrote: > On Sun, Jun 8, 2014 at 8:49 AM, Ethan Furman wrote: > > I don't remember if I almost had this in real code or if I learned about it > > first, but it can definitely be a gotcha. It seems to me that if the try > > block exits with

Re: try/except/finally

2014-06-07 Thread Roy Smith
In article , Mark Lawrence wrote: > On 08/06/2014 01:12, Roy Smith wrote: > > In article , > > Chris Angelico wrote: > > > >> A return statement inside a finally block is code smell. > > > > Not to my nose. It seems like a perfectly reasonable thing to do. > > > > I agree, the code smell is

Re: try/except/finally

2014-06-07 Thread Mark Lawrence
On 08/06/2014 01:12, Roy Smith wrote: In article , Chris Angelico wrote: A return statement inside a finally block is code smell. Not to my nose. It seems like a perfectly reasonable thing to do. I agree, the code smell is the return in the except block. -- My fellow Pythonistas, ask

Re: try/except/finally

2014-06-07 Thread Roy Smith
In article , Chris Angelico wrote: > A return statement inside a finally block is code smell. Not to my nose. It seems like a perfectly reasonable thing to do. -- https://mail.python.org/mailman/listinfo/python-list

Re: try/except/finally

2014-06-07 Thread Chris Angelico
On Sun, Jun 8, 2014 at 8:49 AM, Ethan Furman wrote: > I don't remember if I almost had this in real code or if I learned about it > first, but it can definitely be a gotcha. It seems to me that if the try > block exits with an explicit return, and then the finally block exits with > an explicit re

Re: try/except/finally

2014-06-07 Thread Ethan Furman
On 06/06/2014 11:22 AM, Ned Batchelder wrote: On 6/6/14 1:47 PM, Frank B wrote: Ok; thanks for the underscore and clarification. Just need to adjust my thinking a bit. Did this come up in real code? I've seen this point about finally/return semantics a number of times, but haven't seen re

Re: try/except/finally

2014-06-06 Thread Ned Batchelder
On 6/6/14 1:47 PM, Frank B wrote: Ok; thanks for the underscore and clarification. Just need to adjust my thinking a bit. Did this come up in real code? I've seen this point about finally/return semantics a number of times, but haven't seen real code that needed adjusting based on it. -

Re: try/except/finally

2014-06-06 Thread Frank B
Ok; thanks for the underscore and clarification. Just need to adjust my thinking a bit. -- https://mail.python.org/mailman/listinfo/python-list

Re: try/except/finally

2014-06-06 Thread Roy Smith
In article <0a89c96d-de62-42ad-be48-6107ce10d...@googlegroups.com>, Frank B wrote: > Ok; this is a bit esoteric. > > So finally is executed regardless of whether an exception occurs, so states > the docs. > > But, I thought, if I from my function first, that should take > precedence. > > a

try/except/finally

2014-06-06 Thread Frank B
Ok; this is a bit esoteric. So finally is executed regardless of whether an exception occurs, so states the docs. But, I thought, if I from my function first, that should take precedence. au contraire Turns out that if you do this: try: failingthing() except FailException: return 0 fina

Re: Try-except-finally paradox

2014-01-31 Thread Göktuğ Kayaalp
Terry Reedy writes: I do not have any information on the topic, but I *imagine* that the when RETURN_VALUE opcode is evaluated within the context of an except block, it triggers a check for whether a corresponding finally block exists and should it exist, it is triggered, much like a callback. So

Re: Try-except-finally paradox

2014-01-30 Thread Terry Reedy
On 1/30/2014 7:05 AM, Dave Angel wrote: Jessica Ross Wrote in message: I found something like this in a StackOverflow discussion. def paradox(): ... try: ... raise Exception("Exception raised during try") ... except: ... print "Except after try" ...

Re: Try-except-finally paradox

2014-01-30 Thread Ethan Furman
On 01/30/2014 10:12 AM, Rotwang wrote: On 30/01/2014 06:33, Andrew Berg wrote: On 2014.01.29 23:56, Jessica Ross wrote: I found something like this in a StackOverflow discussion. --> def paradox(): ... try: ... raise Exception("Exception raised during try") ... except: ...

Re: Try-except-finally paradox

2014-01-30 Thread Rotwang
On 30/01/2014 06:33, Andrew Berg wrote: On 2014.01.29 23:56, Jessica Ross wrote: I found something like this in a StackOverflow discussion. def paradox(): ... try: ... raise Exception("Exception raised during try") ... except: ... print "Except after try" ...

Re: Try-except-finally paradox

2014-01-30 Thread Chris Angelico
On Fri, Jan 31, 2014 at 12:11 AM, MRAB wrote: > One of the reasons that the 'with' statement was added was to prevent > the mistake that you've just done. ;-) > > What if the file can't be opened? Yeah, whoops. The open shouldn't be inside try/finally. def func(): output = open("output.txt",

Re: Try-except-finally paradox

2014-01-30 Thread MRAB
On 2014-01-30 13:02, Chris Angelico wrote: On Thu, Jan 30, 2014 at 11:05 PM, Dave Angel wrote: The finally has to happen before any return inside the try or the except. And once you're in the finally clause you'll finish it before resuming the except clause. Since it has a return, that wi

Re: Try-except-finally paradox

2014-01-30 Thread Chris Angelico
On Thu, Jan 30, 2014 at 11:05 PM, Dave Angel wrote: > The finally has to happen before any return inside the try or the > except. And once you're in the finally clause you'll finish it > before resuming the except clause. Since it has a return, that > will happen before the other returns. Th

Re: Try-except-finally paradox

2014-01-29 Thread wxjmfauth
Le jeudi 30 janvier 2014 06:56:16 UTC+1, Jessica Ross a écrit : > I found something like this in a StackOverflow discussion. > > >>> def paradox(): > > ... try: > > ... raise Exception("Exception raised during try") > > ... except: > > ... print "Except after tr

Re: Try-except-finally paradox

2014-01-29 Thread Andrew Berg
On 2014.01.29 23:56, Jessica Ross wrote: > I found something like this in a StackOverflow discussion. def paradox(): > ... try: > ... raise Exception("Exception raised during try") > ... except: > ... print "Except after try" > ... return True > ...

Re: Try-except-finally paradox

2014-01-29 Thread Ian Kelly
On Jan 29, 2014 11:01 PM, "Jessica Ross" wrote: > > I found something like this in a StackOverflow discussion. > >>> def paradox(): > ... try: > ... raise Exception("Exception raised during try") > ... except: > ... print "Except after try" > ... return

Try-except-finally paradox

2014-01-29 Thread Jessica Ross
I found something like this in a StackOverflow discussion. >>> def paradox(): ... try: ... raise Exception("Exception raised during try") ... except: ... print "Except after try" ... return True ... finally: ... print "Finally" ...

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Paul Rubin
Paul Rubin writes: > Re your other post: yes, PEP 363 explains how the "with" statement Whoops, 343. -- http://mail.python.org/mailman/listinfo/python-list

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Paul Rubin
Steven D'Aprano <[EMAIL PROTECTED]> writes: > Yes it does. Eventually f goes out of scope and is closed automatically. Oh right, however you can't really predict when the closure occurs, unless you're relying on current CPython artifacts. Re your other post: yes, PEP 363 explains how the "with" s

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Steven D'Aprano
Replying to my own question... On Thu, 15 Feb 2007 13:17:00 +1100, Steven D'Aprano wrote: > I don't see where the "with" version closes the file either. How does it > know that I want to call the f's close() method, rather than, say, > f.exit() or f.do_something_else()? Ah, I *think* I see... fi

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Steven D'Aprano
On Wed, 14 Feb 2007 18:03:19 -0800, Paul Rubin wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> self.isDataLoaded = False >> try: >> f = open(self.filename, 'rb') >> f.seek(DATA_OFFSET) >> self.__data = f.read(DATA_SIZE) >> self.isDataLoaded = True >> except: >> pass >>

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Paul Rubin
Steven D'Aprano <[EMAIL PROTECTED]> writes: > self.isDataLoaded = False > try: > f = open(self.filename, 'rb') > f.seek(DATA_OFFSET) > self.__data = f.read(DATA_SIZE) > self.isDataLoaded = True > except: > pass > else: > pass > > (apart from being four lines shorter) Your

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Steven D'Aprano
On Wed, 14 Feb 2007 12:09:34 -0800, Paul Rubin wrote: > "redawgts" <[EMAIL PROTECTED]> writes: >> try: >> f = file(self.filename, 'rb') ... >> Can someone tell me what's wrong with the code? > > Various people have explained the error: if the file open attempt > fails, f is n

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread redawgts
Thanks everybody, that helped alot. -- http://mail.python.org/mailman/listinfo/python-list

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Paul Rubin
"redawgts" <[EMAIL PROTECTED]> writes: > try: > f = file(self.filename, 'rb') ... > Can someone tell me what's wrong with the code? Various people have explained the error: if the file open attempt fails, f is never assigned. Doing it the right way (i.e. handling the potentia

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Larry Bates
redawgts wrote: > I keep getting this error "local variable 'f' referenced before > assignment" in the finally block when I run the following code. > > try: > f = file(self.filename, 'rb') > f.seek(DATA_OFFSET) > self.__data = f.read(DATA_SIZE) >

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Andrew Koenig
"redawgts" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I keep getting this error "local variable 'f' referenced before > assignment" in the finally block when I run the following code. > >try: >f = file(self.filename, 'rb') >f.seek(DATA_OFFSET) >

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Robert Kern
redawgts wrote: > I keep getting this error "local variable 'f' referenced before > assignment" in the finally block when I run the following code. > > try: > f = file(self.filename, 'rb') > f.seek(DATA_OFFSET) > self.__data = f.read(DATA_SIZE) >

Re: try...except...finally problem in Python 2.5

2007-02-14 Thread Jean-Paul Calderone
On 14 Feb 2007 11:41:29 -0800, redawgts <[EMAIL PROTECTED]> wrote: >I keep getting this error "local variable 'f' referenced before >assignment" in the finally block when I run the following code. > >try: >f = file(self.filename, 'rb') >f.seek(DATA_OFFSET) >

try...except...finally problem in Python 2.5

2007-02-14 Thread redawgts
I keep getting this error "local variable 'f' referenced before assignment" in the finally block when I run the following code. try: f = file(self.filename, 'rb') f.seek(DATA_OFFSET) self.__data = f.read(DATA_SIZE) self.isDataLoaded = True

Re: Exception handling code (try/except/finally)

2005-03-07 Thread Michael Hoffman
djw wrote: c.l.p- I am having trouble understanding how one is supposed to correctly utilize try:...except:...finally: in real code. If I have a block of code like: def foo(): try: ... some code that can raise an exception ... finally: ... do some cleanup

Exception handling code (try/except/finally)

2005-03-07 Thread djw
c.l.p- I am having trouble understanding how one is supposed to correctly utilize try:...except:...finally: in real code. If I have a block of code like: def foo(): try: ... some code that can raise an exception ... finally: ... do some cleanup