Basic question about speed/coding style/memory

88888 Dihedral dihedral88888 at googlemail.com
Mon Jul 23 23:48:37 CEST 2012


Chris Angelico於 2012年7月21日星期六UTC+8下午5時04分12秒寫道:
> On Sat, Jul 21, 2012 at 5:33 PM, Jan Riechers <janpeterr at freenet.de> 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
> 
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




More information about the Python-list mailing list