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 -- http://mail.python.org/mailman/listinfo/python-list