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

[Alf P. Steinbach]

* 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.

I'm sorry, but that requires a definition of "constant" that explicitly excludes 
routine arguments, which is like saying horses are not mammals, just "because".

There are two sensible definitions of "constant": compile time constant, and 
constant-after-initialization.

And since Python doesn't have or support user defined compile time (named) 
constants even in the way that a programmer views the execution of a program, 
only the const after initialization meaning can /reasonably/ apply.

I hope you see that with the constant-after-initialization meaning it's rather 
irrelevant that an argument's value "will vary according to [the actual 
argument]"  --  for an argument A, id(A) does in general not vary after 
initialization, after creation of A; and it can certainly not vary before!

Consider some C++ code:

   void foo( SomeType const v )
   {
       // Here the name v is constant: that name's value can't change.
       // (Except that in C++ you can do anything by using low-level stuff.)
   }

As the comment there exemplifies, in addition to the 2 main meanings of 
constness one can differentiate between constness at different levels of an 
expression, e.g., in Python, with respect to what the language enforces,

   s = "blah"

is a non-constant name referring to a constant (immutable value), while

   a = ["blah"]

is a non-constant name referring to a non-constant value (a Python 'list') 
containing a constant value  --  but with respect to intended constness there 
might be more constness here, although there can't be less.

Since Python doesn't support constness enforcement, your statement that routine 
arguments are almost never constants must refer to their actual usage, i.e. 
intention. It may be the case that in most code you're familiar with routine 
arguments are generally modified. And/or it may be that in code you're familiar 
with routines regularly modify the objecs that their arguments refer to, i.e. 
that the arguments are constant names referring to mutable objects.

In code that I'm familiar with, but that's admittedly mostly in other languages, 
most argument names are constant at the top level of constness, i.e., translated 
to Python, id(A) does generally not change when A is a formal argument.


> (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.)

Huh.


>> 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.

To be pedantic, original routine names are usually absolutely not meant to be 
assigned to.

If you have

   def foo(): whatever()

you simply shouldn't, in general, do

   foo = bar

I think you understood that, i.e., that the above comment of yours is just rhetoric?


> As far as I know, no programming language provides a standard facility 
> for renaming entities, be they data or routines:

Eiffel (IIRC) and C++ come pretty close.

E.g., in C++:

   int a;
   int& b = a;    // A new name for a.

   b = 123;  // Assigns to a.


> 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

Well, you're off on the wrong track as far as convincing me about something is 
concerned. First, your belief about renaming not being supported by any 
languages is largely incorrect, as shown above. Secondly, I was not talking 
about renaming things  --  that creative interpretation is pretty meaningless...


[snipped the rest, irrelevant]

Cheers & hth.,

- Alf