Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > is there any principle when writing python function

Reply
Thread Tools

is there any principle when writing python function

 
 
smith jack
Guest
Posts: n/a
 
      08-23-2011
i have heard that function invocation in python is expensive, but make
lots of functions are a good design habit in many other languages, so
is there any principle when writing python function?
for example, how many lines should form a function?
 
Reply With Quote
 
 
 
 
Peter Otten
Guest
Posts: n/a
 
      08-23-2011
smith jack wrote:

> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?


Five
 
Reply With Quote
 
 
 
 
Mel
Guest
Posts: n/a
 
      08-23-2011
smith jack wrote:

> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?


It's hard to discuss in the abstract. A function should perform a
recognizable step in solving the program's problem. If you prepared to
write your program by describing each of several operations the program
would have to perform, then you might go on to plan a function for each of
the described operations. The high-level functions can then be analyzed,
and will probably lead to functions of their own.

Test-driven development encourages smaller functions that give you a better
granularity of testing. Even so, the testable functions should each perform
one meaningful step of a more general problem.

> for example, how many lines should form a function?

Maybe as few as one.

def increase (x, a):
return x+a

is kind of stupid, but a more complicated line

def expand_template (bitwidth, defs):
'''Turn Run-Length-Encoded list into bits.'''
return np.array (sum (([bit]*(count*bitwidth) for count, bit in
defs), []), np.int

is the epitome of intelligence. I wrote it myself. Even increase might be
useful:

def increase (x, a):
return x + a * application_dependent_quantity

`increase` has become a meaningful operation in the imaginary application
we're discussing.


For an upper bound, it's harder to say. If you read to the end of a
function and can't remember how it started, or what it did in between, it's
too big. If you're reading on your favourite screen, and the end and the
beginning are more than one page-scroll apart, it might be too big. If it's
too big, factoring it into sub-steps and making functions of some of those
sub-steps is the fix.

Mel.

 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      08-23-2011
In article <(E-Mail Removed)>,
smith jack <(E-Mail Removed)> wrote:

> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?


Enough lines to do what the function needs to do, but no more.

Seriously, break up your program into functions based on logical
groupings, and whatever makes your code easiest to understand. When
you're all done, if your program is too slow, run it under the profiler.
Use the profiling results to indicate which parts need improvement.

It's very unlikely that function call overhead will be a significant
issue. Don't worry about stuff like that unless the profiler shows its
a bottleneck. Don't try to guess what's slow. My guesses are almost
always wrong. Yours will be too.

If your program runs fast enough as it is, don't even bother with the
profiler. Be happy that you've got something useful and move on to the
next thing you've got to do.
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      08-23-2011
In article <j305uo$pmd$(E-Mail Removed)>, Peter Otten <(E-Mail Removed)>
wrote:

> smith jack wrote:
>
> > i have heard that function invocation in python is expensive, but make
> > lots of functions are a good design habit in many other languages, so
> > is there any principle when writing python function?
> > for example, how many lines should form a function?

>
> Five


Five is right out.
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      08-23-2011
smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?


Don't compromise the design and clarity of your code just because you heard
some rumors about performance. Also, for any performance question, please
consult a profiler.

Uli

--
Domino Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      08-23-2011
smith jack wrote:

> i have heard that function invocation in python is expensive,


It's expensive, but not *that* expensive. Compare:

[steve@sylar ~]$ python3.2 -m timeit 'x = "abc".upper()'
1000000 loops, best of 3: 0.31 usec per loop
[steve@sylar ~]$ python3.2 -m timeit -s 'def f():
return "abc".upper()' 'f()'
1000000 loops, best of 3: 0.53 usec per loop

So the function call is nearly as expensive as this (very simple!) sample
code. But in absolute terms, that's not very expensive at all. If we make
the code more expensive:

[steve@sylar ~]$ python3.2 -m timeit '("abc"*1000)[2:995].upper().lower()'
10000 loops, best of 3: 32.3 usec per loop
[steve@sylar ~]$ python3.2 -m timeit -s 'def f(): return ("abc"*1000
[2:995].upper().lower()' 'f()'
10000 loops, best of 3: 33.9 usec per loop

the function call overhead becomes trivial.

Cases where function call overhead is significant are rare. Not vanishingly
rare, but rare enough that you shouldn't worry about them.


> but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?


About as long as a piece of string.

A more serious answer: it should be exactly as long as needed to do the
smallest amount of work that makes up one action, and no longer or shorter.

If you want to maximise the programmer's efficiency, a single function
should be short enough to keep the whole thing in your short-term memory at
once. This means it should consist of no more than seven, plus or minus
two, chunks of code. A chunk may be a single line, or a few lines that
together make up a unit, or if the lines are particularly complex, *less*
than a line.

http://en.wikipedia.org/wiki/The_Mag...s_or_Minus_Two
http://www.codinghorror.com/blog/200...minus-two.html

(Don't be put off by the use of the term "magical" -- there's nothing
literally magical about this. It's just a side-effect of the way human
cognition works.)

Anything longer than 7±2 chunks, and you will find yourself having to scroll
backwards and forwards through the function, swapping information into your
short-term memory, in order to understand it.

Even 7±2 is probably excessive: I find that I'm most comfortable with
functions that perform 4±1 chunks of work. An example from one of my
classes:

def find(self, prefix):
"""Find the item that matches prefix."""
prefix = prefix.lower() # Chunk #1
menu = self._cleaned_menu # Chunk #2
for i,s in enumerate(menu, 1): # Chunk #3
if s.lower().startswith(prefix):
return i
return None # Chunk #4

So that's three one-line chunks and one three-line chunk.



--
Steven

 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      08-23-2011
On 2011-08-23, smith jack <(E-Mail Removed)> wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?


Lots of them. None of them have to do with performance.

> for example, how many lines should form a function?


Between zero (which has to be written "pass") and a few hundred. Usually
closer to the lower end of that range. Occasionally outside it.

Which is to say: This is the wrong question.

Let us give you the two laws of software optimization.

Law #1: Don't do it.

If you try to optimize stuff, you will waste a ton of time doing things that,
it turns out, are unimportant.

Law #2: (Experts only.) Don't do it yet.

You don't know enough to "optimize" this yet.

Write something that does what it is supposed to do and which you understand
clearly. See how it looks. If it looks like it is running well enough,
STOP. You are done.

Now, if it is too slow, and you are running it on real data, NOW it is time
to think about why it is slow. And the solution there is not to read abstract
theories about your language, but to profile it -- actually time execution and
find out where the time goes.

I've been writing code, and making it faster, for some longish period of time.
I have not yet ever in any language found cause to worry about function call
overhead.

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      08-23-2011
On Aug 23, 6:59*am, smith jack <(E-Mail Removed)> wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?


Everyone here who is suggesting that function bodies should be
confined to ANY length is an idiot. The length of a functions code
block is inconsequential. Don't worry if it too small or too big. It's
not the size that matters, it's the motion of the sources ocean!

A good function can be one line, or a hundred lines. Always use
comments to clarify code and NEVER EVER create more functions only for
the sake of short function bodies, WHY, because all you do is move
confusion OUT OF the function body and INTO the module/class body.

"""Energy can neither be created nor be destroyed: it can only be
transformed from one state to another"""

http://en.wikipedia.org/wiki/Conservation_of_energy
https://sites.google.com/site/thefutureofpython/

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      08-23-2011
On 8/23/2011 11:22 AM, Steven D'Aprano wrote:

> Even 7±2 is probably excessive: I find that I'm most comfortable with
> functions that perform 4±1 chunks of work. An example from one of my
> classes:
>
> def find(self, prefix):
> """Find the item that matches prefix."""
> prefix = prefix.lower() # Chunk #1
> menu = self._cleaned_menu # Chunk #2
> for i,s in enumerate(menu, 1): # Chunk #3
> if s.lower().startswith(prefix):
> return i
> return None # Chunk #4
>
> So that's three one-line chunks and one three-line chunk.


In terms of different functions performed (see my previous post), I see
attribute lookup
assignment
enumerate
sequence unpacking
for-looping
if-conditioning
lower
startswith
return
That is 9, which is enough.

--
Terry Jan Reedy


 
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
Principle Engineer needed Joe Feldman C++ 14 05-06-2010 12:47 AM
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
Webmessenger principle CW ASP .Net 5 09-23-2004 02:14 AM
Dependency Inversion Principle Dilemma Thomas Matthews C++ 12 12-23-2003 08:51 PM
principle of stport std::sort Pavel Pluhacek C++ 2 09-01-2003 05:37 PM



Advertisments