Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments

[Steven D'Aprano]

On Fri, 18 Dec 2009 19:00:48 +0100, Alf P. Steinbach wrote:

> In fact almost no Python
> code does, but then it seems that people are not aware of how many of
> their names are constants and think that they're uppercasing constants
> when in fact they're not. E.g. routine arguments 

Routine arguments are almost never constants, since by definition they 
will vary according to the value passed by the caller.

(The exception is that some formal parameters in Python are given default 
values and flagged as "do not use", e.g. some methods in the random 
module. One might argue that they are constants in the sense that the 
caller is warned not to use them at all.)


> and in particular
> routine NAMES are usually constants, absolutely not meant to be
> modified, but it would be silly to UC...
[emphasis added by me]


The only thing sillier than uppercasing routine names is to confuse the 
name of a thing for the thing it represents. The names of *all* entities, 
whether of constants, variables or routines, are "not meant to be 
modified". As a general rule, programs will no more work if you rename a 
variable 'x' to 'y' than if you rename a function 'f' to 'g' -- that's 
why refactoring requires that any renamings be done carefully. There's no 
need to single out routines for special treatment in that regard.

As far as I know, no programming language provides a standard facility 
for renaming entities, be they data or routines: the closest we have is 
something like Python where you can do this:

# make an entity x
x = 23
# use it
x += 1
# make a new name that refers to the same entity as x
y = x  
# delete the old name
del x
# now use the new name
y += 1

So while it is true that routine names are not meant to be modified, 
neither are variable names (that is, the names of variables) or the names 
of anything else either. But this is not what is meant by "constant": 
being a constant means that the *value*, not the *name*, is never meant 
to change.

It is true that, usually, the names of certain types of object (usually 
functions, classes, methods and modules) are typically expected to not be 
re-bound. Having done this:

def parrot(colour='blue'):
    return "Norwegian %s" % colour.titlecase()


I would *rarely* rebind the name parrot to another object. Rarely, but 
not quite never: I might monkey-patch the function, or decorate it in 
some way, or change the implementation, so such routines aren't quite 
constant in the sense you mean. While it's unusual to vary a function, it 
isn't forbidden.

Even in languages where routines are "first class objects" like ints and 
strings, we treat such objects as special. Even if the function named 
parrot above was expected to never change, I wouldn't describe it as a 
constant. "Constant" and "variable" refer to *data*, not routines or 
other special objects like modules.

It's illustrative to consider what we might do when writing a program 
that does treat functions as data, say, a program that integrated other 
functions. One might very well do something like this:

function_to_be_integrated = math.sin  # a variable
SIMPSONS = integrators.simpsons_method  # a constant
UPPER_RECT = monkey_patch(integrators.upper)
LOWER_RECT = monkey_patch(integrators.lower)

integrate(function_to_be_integrated, 
          limits=(-math.pi/2, math.pi),
          method=SIMPSONS
          )

This would clearly indicate that `function_to_be_integrated` holds 
variable data (which happens to be a function) while `SIMPSONS` etc are 
expected to hold constant data (which also happen to be functions).


-- 
Steven