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" yet.) > > 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 > statement. 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. -- Steven D'Aprano _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
