[Tutor] Simple Python Program
steve at pearwood.info
Sun Aug 1 07:50:13 CEST 2010
On Sun, 1 Aug 2010 01:11:41 pm bob gailer wrote:
> On 7/31/2010 8:24 PM, Steven D'Aprano wrote:
> > On Sun, 1 Aug 2010 04:35:03 am bob gailer wrote:
> >> Continue to avoid writing functions. They are not necessary for
> >> such a simple program.
> > That is *terrible* advice. Absolutely awful.
> Well I disagree. I was trying to steer the OP to get the simplest
> possible program running, then do incremental expansion.
In hindsight, my post was a bit harsh. I actually agreed with nearly
everything else you said, which I should have said. So I would like to
apologise for the way I said what I said.
> In my understanding user defined functions serve these purposes:
> 1 - modularizing large programs
Leave out the "large", and you would be right. There is no limit to how
small a program need be before using functions becomes appropriate. A
one line program could be better off split into functions if the line
is complex enough.
> 2 - factoring out common code
> 3 - providing callbacks
> 4 - choosing callable objects from some collection.
> 5 - providing a main function for the if __name__ == "__main__" idiom
> 6 - what else can we think of?
Code reuse, ease of testing, simplicity of debugging, separating the
interface from the implementation, avoiding side-effects, writing
self-documenting code, ease of refactoring, simplifying redesign, and
probably many others.
> None of these are needed in this simple case.
Whether needed or not, splitting the code into small, easily testable,
self-contained pieces is never a bad thing to do. Sometimes, rarely,
for performance reasons you might choose to give up all those positives
in order to win a bit of extra performance in a critical section of
code, but that's the only reason I can think of to *actively* avoid the
use of functions. (As opposed to passively avoid them because you just
started programming yesterday and haven't got to "Chapter 3: Functions"
> > Functions should not be avoided unless necessary. Functions should
> > be used unless there is a compelling reason to avoid them.
> Once the OP has succeeded in getting some program running he will
> experience some relief and satisfaction. Then I think it is time to
> add language features. But not just for the sake of using them.
This is an excellent point. I might take the OP many, many hours, or
days, or weeks, of effort to get the entire program working. The
process until that point is just frustration after frustration as
things go wrong. Until the entire function is working, it's hard to see
any positive progress because it's just bug after bug after bug.
Or he can write one function that does one small thing, debug that, and
get a sense of satisfaction that this function, at least, is working as
designed, before going on to write the next function. Functions are not
just for the compiler, they are for the human reader and writer too.
It's easier to wrap your brain around a small, self-contained piece of
code that does one thing in three or five or ten lines, than a
comparatively large piece of code that requires thirty or fifty.
> > This is not 1972 any more, and we're not teaching kids to write
> > spaghetti code with BASIC and GOTO.
> Functions have no relationship to avoiding spaghetti code. Python
> makes spaghetti code impossible since it lacks a goto or equivalent
Nonsense. Procedural programming (the use of functions, procedures, or
sub-routines) was created partly to avoid spaghetti code. The primary
reason GOTO is to be avoided is because of the tendency to lead to
spaghetti. (Technically a function call is a specialist kind of GOTO.
In early BASIC, it would be like a GOSUB. But it is a structured jump,
tamed and on a leash rather than running wild like GOTO.)
Of course, the use of functions in and of itself does not guarantee you
won't write spaghetti code. Object oriented programming sadly lends
itself to class-based spaghetti (fettuccine perhaps?). But that's not
likely to be a risk here.
> > Functions, or their object-oriented
> > equivalent methods, are *the* single most important feature of
> > programming. And they're simple too
> Well - almost simple. Until you get into issues like global vs local
> names, positional vs keyword arguments, required vs optional
> arguments, default values (especially mutable objects), * and **,
> generator functions, magic methods, nested defs, decorators, ....
Of course. But apart from the distinction between local and global,
everything else is optional.
> > -- they might not be the first thing you teach an absolute newbie
> > who has never programmed before
> That is what our OP appears to be.
He's experienced enough to be attempting to write functions. I don't
believe you are doing him a favour by discouraging him.
More information about the Tutor