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


Groups > comp.lang.python > #25930

Re: Basic question about speed/coding style/memory

Newsgroups comp.lang.python
Date 2012-07-23 14:48 -0700
References <500A5B47.1060805@freenet.de> <mailman.2370.1342861455.4697.python-list@python.org>
Subject Re: Basic question about speed/coding style/memory
From 88888 Dihedral <dihedral88888@googlemail.com>
Message-ID <mailman.2505.1343080119.4697.python-list@python.org> (permalink)

Show all headers | View raw


Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道:
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers &lt;janpeterr@freenet.de&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 do that.
> 
> &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&#39;t bother doing most of this
> function&#39;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 one place:
> 
> def func(x,y,z):
>   if x&lt;0:
>     y+=5
>     return
>   if y&lt;0:
>     raise PEBKAC(&quot;There&#39;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&#39;t think there&#39;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&#39;s doing, and let the execution take care
> of itself.
> 
> ChrisA

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Basic question about speed/coding style/memory Chris Angelico <rosuav@gmail.com> - 2012-07-21 19:04 +1000
  Re: Basic question about speed/coding style/memory 88888 Dihedral <dihedral88888@googlemail.com> - 2012-07-23 14:48 -0700
  Re: Basic question about speed/coding style/memory 88888 Dihedral <dihedral88888@googlemail.com> - 2012-07-23 14:48 -0700

csiph-web