Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #72872 > unrolled thread

try/except/finally

Back to article view | Back to comp.lang.python

Contents

  try/except/finally Frank B <fbicknel@gmail.com> - 2014-06-06 10:30 -0700
    Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-06 13:39 -0400
      Re: try/except/finally Frank B <fbicknel@gmail.com> - 2014-06-06 10:47 -0700
        Re: try/except/finally Ned Batchelder <ned@nedbatchelder.com> - 2014-06-06 14:22 -0400
        Re: try/except/finally Ethan Furman <ethan@stoneleaf.us> - 2014-06-07 15:49 -0700
        Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-08 09:47 +1000
          Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-07 20:12 -0400
            Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-08 02:10 +0100
              Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-07 21:32 -0400
              Re: try/except/finally Marko Rauhamaa <marko@pacujo.net> - 2014-06-08 10:12 +0300
                Re: try/except/finally Joshua Landau <joshua@landau.ws> - 2014-06-08 18:57 +0100
                Re: try/except/finally Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-08 12:07 -0600
                Re: try/except/finally Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-08 12:02 -0600
          Re: try/except/finally Rustom Mody <rustompmody@gmail.com> - 2014-06-07 20:58 -0700
            Re: try/except/finally Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2014-06-10 09:27 +0200
              Re: try/except/finally Marko Rauhamaa <marko@pacujo.net> - 2014-06-10 12:07 +0300
              Re: try/except/finally Rustom Mody <rustompmody@gmail.com> - 2014-06-10 05:06 -0700
                Re: try/except/finally Skip Montanaro <skip@pobox.com> - 2014-06-10 13:11 -0500
                  Re: try/except/finally Rustom Mody <rustompmody@gmail.com> - 2014-06-10 19:01 -0700
              Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-10 19:14 +0100
                Re: try/except/finally Grant Edwards <invalid@invalid.invalid> - 2014-06-10 18:48 +0000
                  Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 06:37 +1000
                    Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-10 16:38 -0400
                      Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 06:43 +1000
                      Re: try/except/finally Ethan Furman <ethan@stoneleaf.us> - 2014-06-10 13:43 -0700
                      Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-10 22:59 +0100
                    Re: try/except/finally Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-06-11 00:00 +0000
                      Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 10:12 +1000
                        Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-10 20:22 -0400
                      Re: try/except/finally Tim Delaney <timothy.c.delaney@gmail.com> - 2014-06-11 10:40 +1000
                      Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-11 01:53 +0100
                      Re: try/except/finally Chris Angelico <rosuav@gmail.com> - 2014-06-11 11:00 +1000
                      Re: try/except/finally Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-06-11 02:06 +0100
                      Re: try/except/finally alister <alister.nospam.ware@ntlworld.com> - 2014-06-11 08:35 +0000
                        Re: try/except/finally Roy Smith <roy@panix.com> - 2014-06-11 08:50 -0400
                Re: try/except/finally alister <alister.nospam.ware@ntlworld.com> - 2014-06-10 19:02 +0000
      Re: try/except/finally Joshua Landau <joshua@landau.ws> - 2014-06-08 19:05 +0100
    Re:try/except/finally Dave Angel <davea@davea.name> - 2014-06-07 21:59 -0500
      Re: try/except/finally Philip Shaw <jnufcvyvuc@tznvy.pbz> - 2014-06-09 09:13 +0000
        Re: try/except/finally Marko Rauhamaa <marko@pacujo.net> - 2014-06-09 12:40 +0300
          Re: try/except/finally Shiyao Ma <i@introo.me> - 2014-06-10 00:23 +0800
          Re: try/except/finally Skip Montanaro <skip@pobox.com> - 2014-06-09 11:56 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#73114

On 2014-06-10, Mark Lawrence <breamoreboy@yahoo.co.uk> 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 SNAFU or
> whatever.

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 and needed to be fixed.  Usually the
addition of a 'fail' label and a few gotos allowed me to throw out all
sorts of complexly nested if/else blocks, status flags, and
unnecessary while loops.  Usually you can reduce the number of lines
of code (sometimes by half or more) while also reducing the number and
nesting of control structures.  And when you're done it works right!

-- 
Grant Edwards               grant.b.edwards        Yow! LOOK!!  Sullen
                                  at               American teens wearing
                              gmail.com            MADRAS shorts and "Flock of
                                                   Seagulls" HAIRCUTS!

[toc] | [prev] | [next] | [standalone]

#73122

On Wed, Jun 11, 2014 at 4:48 AM, Grant Edwards <invalid@invalid.invalid> 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 and needed to be fixed.  Usually the
> addition of a 'fail' label and a few gotos allowed me to throw out all
> sorts of complexly nested if/else blocks, status flags, and
> unnecessary while loops.  Usually you can reduce the number of lines
> of code (sometimes by half or more) while also reducing the number and
> nesting of control structures.  And when you're done it works right!

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 suboptimal code.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73123

In article <mailman.10972.1402432630.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> 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 suboptimal code.

How about, "Don't use PHP"?

[toc] | [prev] | [next] | [standalone]

#73125

On Wed, Jun 11, 2014 at 6:38 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.10972.1402432630.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> 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 suboptimal code.
>
> How about, "Don't use PHP"?

Actually, that one might fit now. In years past, that advice would
often lead you to write very expensive code, because it couldn't be
run on a cheap web host - if you write something in Python, you have
to pay through the nose, but any piece-of-rubbish host will give you
PHP. That may now be changing, though.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73135

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't at some point cause suboptimal code.
>
> How about, "Don't use PHP"?

Sounds like the exception that proves the rule!  ;)

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#73138

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 which, if taken as
>>> an inviolate rule, doesn't at some point cause suboptimal code.
>>
>> How about, "Don't use PHP"?
>
> Sounds like the exception that proves the rule!  ;)
>
> --
> ~Ethan~

After that one please consider yourself fortunate that the UK, amongst 
other countries, no longer has the death penalty.  I guess that The 
Comfy Chair will have to suffice :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#73141

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://import-that.dreamwidth.org/

[toc] | [prev] | [next] | [standalone]

#73143

On Wed, Jun 11, 2014 at 10:00 AM, Steven D'Aprano
<steve+comp.lang.python@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
>> rule, doesn't at some point cause suboptimal code.
>
> "Don't try to program while your cat is sleeping on the keyboard."

Hmm. I've never actually heard that one. Is it commonly taught in
programming classes? Because I haven't taken any.

ChrisA

[toc] | [prev] | [next] | [standalone]

#73144

> On Wed, Jun 11, 2014 at 10:00 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > "Don't try to program while your cat is sleeping on the keyboard."

In article <mailman.10989.1402445543.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:
> Hmm. I've never actually heard that one. Is it commonly taught in
> programming classes? Because I haven't taken any.

A picture of a cat sleeping on your keyboard...

$ ps l
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1010  4768  4660  20   0   5904   352 n_tty_ S+   pts/1      0:00 cat

[toc] | [prev] | [next] | [standalone]

#73146

[Multipart message — attachments visible in raw view] — view raw

On 11 June 2014 10:00, Steven D'Aprano <steve+comp.lang.python@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
> > rule, doesn't at some point cause suboptimal code.
>
> "Don't try to program while your cat is sleeping on the keyboard."
>

Lying down, the weight is spread across the whole keyboard so you're
unlikely to suffer extra keypresses due to the cat. So if you're a
touch-typist that one may not be too bad (depending on how easily their fur
gets up your nose).

Now, a cat *standing* on the keyboard, between you and the monitor, and
rubbing his head against your hands, is a whole other matter.

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#73147

On 11/06/2014 01:40, Tim Delaney wrote:
> On 11 June 2014 10:00, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info
> <mailto:steve+comp.lang.python@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
>      > rule, doesn't at some point cause suboptimal code.
>
>     "Don't try to program while your cat is sleeping on the keyboard."
>
>
> Lying down, the weight is spread across the whole keyboard so you're
> unlikely to suffer extra keypresses due to the cat. So if you're a
> touch-typist that one may not be too bad (depending on how easily their
> fur gets up your nose).
>
> Now, a cat *standing* on the keyboard, between you and the monitor, and
> rubbing his head against your hands, is a whole other matter.
>
> Tim Delaney
>
>

Does it make any difference if the cat is European or African?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#73148

On Wed, Jun 11, 2014 at 10:53 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> Does it make any difference if the cat is European or African?

What? I don't know..... AAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!

ChrisA

[toc] | [prev] | [next] | [standalone]

#73150

On 11/06/2014 02:00, Chris Angelico wrote:
> On Wed, Jun 11, 2014 at 10:53 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> Does it make any difference if the cat is European or African?
>
> What? I don't know..... AAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!
>
> ChrisA
>

Awfully sorry, it's 2 a.m. here, next time I'll try to remember to 
mention cats from other continents like America, Asia and Antartica. 
Did I get all of them? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#73160

On Wed, 11 Jun 2014 00:00:49 +0000, 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 sleeping on the keyboard."

My cat is a better programmer than I am !



-- 
Hors d'oeuvres -- a ham sandwich cut into forty pieces.
		-- Jack Benny

[toc] | [prev] | [next] | [standalone]

#73169

In article <NxUlv.352165$uI3.258913@fx18.am4>,
 alister <alister.nospam.ware@ntlworld.com> wrote:

> On Wed, 11 Jun 2014 00:00:49 +0000, 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 sleeping on the keyboard."
> 
> My cat is a better programmer than I am !

My girlfriend's cat is smarter than me!

[toc] | [prev] | [next] | [standalone]

#73115

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 statement
>>> considered harmful" and became famous.
>>
>> And became widely misunderstood. If anybody would read the whole what
>> he wrote, people would learn that he doesn't criticise the *use* of
>> goto, but he wants the *replacement* of goto with something else (like
>> exceptions).
>>
>> As C doesn't have exceptions, goto is in many cases the simplest and
>> easiest way of handling errors.
>>
>> Essentially, you can write both good and bad code both with and without
>> goto.
>>
>> Thomaas
> 
> 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 SNAFU or whatever.



once the compiler gets hold of it all the CPU has to work with are goto 
variants, jump if equal etc.(I don't know the actual x86 assembler but it 
is the same on all processors)
-- 
(It is an old Debian tradition to leave at least twice a year ...)
	-- Sven Rudolph

[toc] | [prev] | [next] | [standalone]

#72985

On 6 June 2014 18:39, Roy Smith <roy@panix.com> 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 None: sys.settrace(lambda frame, event, arg: None)

def break_n(n):
    frame = sys._getframe().f_back

    for _ in range(n):
        frame.f_trace = skip_function_tracer
        frame = frame.f_back

def skip_function_tracer(frame, event, arg):
    try:
        # Skip this line
        while True:
            frame.f_lineno += 1

    except ValueError as e:
        # Finished tracing function; remove trace
        pass

---

# Thing_you_run.py

from BreakN import break_n

def foo():
    try:
        print("I am not skipped")
        break_n(1)
        print("I am skipped")
        ...
    finally:
        print("I am skipped")
        ...

foo()
#>>> I am not skipped

[toc] | [prev] | [next] | [standalone]

#72950

Frank B <fbicknel@gmail.com> 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 <return> from my function first, that should take precedence.
> 
> au contraire
> 
> Turns out that if you do this:
> 
> try:
>   failingthing()
> except FailException:
>   return 0
> finally:
>   return 1
> 
> Then finally really is executed regardless... even though you told it to return.
> 
> That seems odd to me.
> 

The thing that's odd to me is that a return is permissible inside
 a finally block. That return
should be at top level,  even with the finally line. And of course
 something else should be in the body of the finally
 block.

If you wanted the finally block to change the return value,  it
 should do it via a variable.

retval = 0 
try:
     failingthing()
except FailException:
     return retval
finally:
     retval =1 
return something

I imagine the finally clause was designed to do cleanup, like
 closing files.  And it certainly predated the with statement.
 

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#73013

On 2014-06-08, Dave Angel <davea@davea.name> wrote:
> Frank B <fbicknel@gmail.com> 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 <return> from my function first, that should take precedence.
>> 
>> au contraire
>> 
>> Turns out that if you do this:
>> 
>> try:
>>   failingthing()
>> except FailException:
>>   return 0
>> finally:
>>   return 1
>> 
>> Then finally really is executed regardless... even though you told it to return.
>> 
>> That seems odd to me.
>> 
>
> The thing that's odd to me is that a return is permissible inside
>  a finally block. That return
> should be at top level,  even with the finally line. And of course
>  something else should be in the body of the finally
>  block.

It does have some legitimate uses, for example:

try:
    failingThing()
finally:
    simple_cleanup()
    if(that_worked())
        return
    complicated
        cleanup
    with
        lots
            of
        blocks

OTOH, it could just be that Guido didn't think of banning it when
exceptions were first added and doesn't want to introduce an
incompatability later.

[toc] | [prev] | [next] | [standalone]

#73018

Philip Shaw <jnufcvyvuc@tznvy.pbz>:

> 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 with static type checking.


Marko

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web