Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Basic question about speed/coding style/memory

Reply
Thread Tools

Re: Basic question about speed/coding style/memory

 
 
Chris Angelico
Guest
Posts: n/a
 
      07-21-2012
On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <(E-Mail Removed)> wrote:
> Block
> #----------------------------------
> if statemente_true:
> doSomething()
> else:
> doSomethingElseInstead()
>
> #----------------------------------


This means, to me, that the two options are peers - you do this or you do that.

> versus this block:
> #----------------------------------
> if statement_true:
> doSomething()
> return
>
> doSomethingElseInstead()
>
> #----------------------------------


This would be for an early abort. Don't bother doing most of this
function's work, just doSomething. Might be an error condition, or
perhaps an optimized path.

Definitely for error conditions, I would use the second option. The
"fail and bail" notation keeps the entire error handling in one place:

def func(x,y,z):
if x<0:
y+=5
return
if y<0:
raise PEBKAC("There's an idiot here somewhere")
# ... do the rest of the work

Note the similarity between the control structures. Raising an
exception immediately terminates processing, without polluting the
rest of the function with an unnecessary indentation level. Early
aborting through normal function return can do the same thing.

But this is purely a matter of style. I don't think there's any
significance in terms of processing time or memory usage, and even if
there is, it would be dwarfed by considerations of readability. Make
your code look like what it's doing, and let the execution take care
of itself.

ChrisA
 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      07-23-2012
Chris Angelico於 2012年7月21日星期*UTC+8下午5時04分12秒 寫道:
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers &lt;(E-Mail Removed)&gt; wrote:
> &gt; Block
> &gt; #----------------------------------
> &gt; if statemente_true:
> &gt; doSomething()
> &gt; else:
> &gt; doSomethingElseInstead()
> &gt;
> &gt; #----------------------------------
>
> This means, to me, that the two options are peers - you do this or you dothat.
>
> &gt; versus this block:
> &gt; #----------------------------------
> &gt; if statement_true:
> &gt; doSomething()
> &gt; return
> &gt;
> &gt; doSomethingElseInstead()
> &gt;
> &gt; #----------------------------------
>
> This would be for an early abort. Don't bother doing most of this
> function's work, just doSomething. Might be an error condition, or
> perhaps an optimized path.
>
> Definitely for error conditions, I would use the second option. The
> &quot;fail and bail&quot; notation keeps the entire error handling in oneplace:
>
> def func(x,y,z):
> if x&lt;0:
> y+=5
> return
> if y&lt;0:
> raise PEBKAC(&quot;There's an idiot here somewhere&quot
> # ... do the rest of the work
>

This is the caller responsible style when passing parameters to
functions.


Checking types of parameters both in the caller and the callee
does slow down a little bit.



> Note the similarity between the control structures. Raising an
> exception immediately terminates processing, without polluting the
> rest of the function with an unnecessary indentation level. Early
> aborting through normal function return can do the same thing.
>
> But this is purely a matter of style. I don't think there's any
> significance in terms of processing time or memory usage, and even if
> there is, it would be dwarfed by considerations of readability. Make
> your code look like what it's doing, and let the execution take care
> of itself.
>
> ChrisA


 
Reply With Quote
 
 
 
 
88888 Dihedral
Guest
Posts: n/a
 
      07-23-2012
Chris Angelico於 2012年7月21日星期*UTC+8下午5時04分12秒 寫道:
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers &lt;(E-Mail Removed)&gt; wrote:
> &gt; Block
> &gt; #----------------------------------
> &gt; if statemente_true:
> &gt; doSomething()
> &gt; else:
> &gt; doSomethingElseInstead()
> &gt;
> &gt; #----------------------------------
>
> This means, to me, that the two options are peers - you do this or you dothat.
>
> &gt; versus this block:
> &gt; #----------------------------------
> &gt; if statement_true:
> &gt; doSomething()
> &gt; return
> &gt;
> &gt; doSomethingElseInstead()
> &gt;
> &gt; #----------------------------------
>
> This would be for an early abort. Don't bother doing most of this
> function's work, just doSomething. Might be an error condition, or
> perhaps an optimized path.
>
> Definitely for error conditions, I would use the second option. The
> &quot;fail and bail&quot; notation keeps the entire error handling in oneplace:
>
> def func(x,y,z):
> if x&lt;0:
> y+=5
> return
> if y&lt;0:
> raise PEBKAC(&quot;There's an idiot here somewhere&quot
> # ... do the rest of the work
>

This is the caller responsible style when passing parameters to
functions.


Checking types of parameters both in the caller and the callee
does slow down a little bit.



> Note the similarity between the control structures. Raising an
> exception immediately terminates processing, without polluting the
> rest of the function with an unnecessary indentation level. Early
> aborting through normal function return can do the same thing.
>
> But this is purely a matter of style. I don't think there's any
> significance in terms of processing time or memory usage, and even if
> there is, it would be dwarfed by considerations of readability. Make
> your code look like what it's doing, and let the execution take care
> of itself.
>
> ChrisA


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
TurboTax Basic vs. Taxcut Basic? Sharp Dressed Man Computer Support 1 01-12-2009 12:52 PM
What is the difference between Visual Basic.NET and Visual Basic 6? Jimmy Dean Computer Support 3 07-25-2005 07:05 AM
Re: Python interpreter in Basic or a Python-2-Basic translator. rrr@ronadam.com Python 0 05-02-2005 01:48 PM
Python interpreter in Basic or a Python-2-Basic translator. Engineer Python 6 05-01-2005 10:16 PM
Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET Jaime MCSD 2 09-20-2003 05:16 AM



Advertisments