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

[Steven D'Aprano]

On Sat, 19 Dec 2009 01:25:48 +0100, Alf P. Steinbach wrote:

> That said, and a bit off-tangent to your comment's main thrust, the time
> spent on coding that repeated-division-by-2 optimization would, I think,
> be better spent googling "Collatz Conjecture"  --  avoiding writing
> /any/ code. ;-)

That's a strange thing to say. 


>> Now, it's a different story if you're using the gmpy module. You DON'T
>> want to use literals in loops involving gmpy, because they would have
>> to be coerced to .mpz's on every pass through the loop.
[...]
> Yeah, good point. Few languages have compile time evaluation of
> logically constant expressions. 

Surely that's an implementation issue rather than a language issue.


> C++0x will have that feature (called
> 'constexpr' IIRC) but in Python, current C++ etc. it's just a good idea
> to precompute values, and name them, rather than computing them again
> and again where they're needed.

CPython 2.5 and on has a keyhole optimizer that replaces many constant 
expressions with pre-computed values.

# Python 2.4
>>> dis.dis(compile('1+1', '', 'eval'))
  0           0 LOAD_CONST               0 (1)
              3 LOAD_CONST               0 (1)
              6 BINARY_ADD
              7 RETURN_VALUE

# Python 2.5
>>> dis.dis(compile('1+1', '', 'eval'))
  1           0 LOAD_CONST               1 (2)
              3 RETURN_VALUE


Unfortunately it doesn't help Mensanator's case, because there's no way 
to tell the compiler to generate mpz objects instead of int objects, and 
expressions such as gmpy.mpz(0) are not recognised as compile-time 
constants.


>> Mine does when I use gmpy. Otherwise, the notion that "most names are
>> constants" is generally false.
> 
> No, it depends on what you mean by "constant". 

All names are constant. Always. The Python language does not support 
renaming names -- as far as I know, no language does.


> The problem with Python,
> as Google noted, is that the language is so excessively dynamic: even
> names of routines are variables, 

Don't say that, that is confusing the name with the value. The terms 
"constant" and "variable" refer to the values bound to a name, not the 
name itself: what you mean is that even routines are variables.

Consider the following Pascal declaration:

const
  a = 1;
var
  b: integer;

Neither name 'a' nor 'b' ever change; a is always a and b is always b. 
You wouldn't describe b as a constant because the name never changes, 
would you? What matters is that the value assigned to the name can, or 
can't, be changed by the caller.

Like any other language, Python *names* are always constant: you can 
create them at will (without needing a declaration); you can delete them 
(with the del statement, something Pascal doesn't allow you to do); but 
there's no way to change a name once it exists. Obviously it would be 
misleading to claim that Python name/object bindings ("variables") are 
therefore constant because of this.

So how would I say what you are trying to say, but in a less-misleading 
fashion?

Names can always (well, almost -- there are a few exceptions) be rebound, 
regardless of whether they are currently bound to a data object (string, 
int, float...) or a routine (function, method...). Since the name by 
which we refer to a function can be rebound, we refer to the name/object 
binding as variable rather than constant -- exactly the same as any other 
name/object binding.

Or the shorter way:

Since all names can be rebound, regardless of what value they have (int, 
string, function, whatever) all names are variables and Python has no 
constants other than special pre-defined names like None.



> and there /are/ no named user defined
> constants except logically, in the programmer's mind. 

Yes, that is correct, although there are tricks you can do to make 
slightly-more-constant-like constants, such as Alex Martelli's "constant 
module" recipe in the Cookbook, but there are no true constants in Python.


> And logically
> (that is, at the "in the programmer's mind" level), if you define
> "constant" as a name whose value will not change after initialization,
> then routine names are constants.

Some languages enforce that, and in those languages, it makes sense to 
describe functions as constants. Python is not one of those languages.


> However, if you define "constant" as only a global scope (that is,
> module scope) name that denotes a boolean, numerical or string or Null
> value and that doesn't change after initialization, then your statement
> about the scarcity of constants appears to be true, but using a
> practically useless definition.

I won't speak for Mensanator, but I wouldn't be so restrictive about the 
*types* of data that constants can hold. Not in Python, at least, other 
languages can and do limit the types of constants to a handful of 
predefined types known to the compiler.

Nor would I say that "constants" (note the scare-quotes) can only occur 
in module scope. There's nothing wrong with naming "constants" in other 
scopes, although I must admit I'm a tad less consistent about doing so 
than I should.



-- 
Steven