Dreaming of new generation IDE

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sun Feb 7 02:57:24 CET 2010

On Sun, 07 Feb 2010 01:34:14 +0000, bartc wrote:

> For a real-world example, it means instead of having a room with a
> light-switch in it, if I *know* I want the light on or off, I should
> have two rooms: one with the light permanently on, and one with it
> permanently off, and just walk into the right one.

I don't think you can apply real-world analogies to software in that way. 
They're too different.

Think of the objections to having two rooms, one permanently lit up, the 
other permanently not:

(1) Having two rooms is expensive and wasteful of physical space, which 
is in short supply.

(2) You typically use rooms for storing things (furniture and smaller 
objects), having two rooms mean you would need to clone every object 
inside it and somehow keep them in perfect synchronisation.

(3) the light that is always on will use electricity 24 hours a day, 
regardless of whether you are inside it or not.

But none of those objections apply to functions:

(1) Functions are cheap and live in memory, which is not in short supply 
unless you're programming for an embedded device.

(1a) Even if you are programming in a device that is short of memory, the 
overhead of a second function is minimal. There's little difference 

def func(flag):
    if flag:


def funcA():

def funcB():

for any non-trivial code blocks, particularly if any common code is 
factored out into another function which you call.

(2) Functions aren't typically used for storage, and when they need 
external data, it is easy to have them access a common data store.

(3) Functions don't use CPU cycles just by existing.


More information about the Python-list mailing list