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

[Alf P. Steinbach]

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

No. The code shown was like attacking Fermat's last theorem with a little Python 
script checking out number triplets. It's already been done (not to mention that 
that theorem's been proven, although that's, AFAIK, not the case for Collatz').


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

No, it isn't.

An optimizer can only do so much, as you yourself note below!

With language support it's a very different matter because guarantees propagate 
so that sophisticated analysis is no longer necessary: the compiler /knows/, 
because it's explicitly being told.


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

See?

;-)


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

No-ones been talking about renaming names. I think that's purely rhetorical on 
your part but it may be that you really believe so. In the latter case, just try 
to interpret statements so that they're meaningful instead of meaningless. :-)


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

Nope.


> The terms 
> "constant" and "variable" refer to the values bound to a name, not the 
> name itself:

I'm sorry, that's incorrect.

Quote from §4.1 "Naming and binding" of the Python 3.1.1 language spec:

"If a name is bound in a block, it is a local variable of that block, unless 
declared as nonlocal. If a name is bound at the module level, it is a global 
variable. (The variables of the module code block are local and global.) If a 
variable is used in a code block but not defined there, it is a free variable."


> what you mean is that even routines are variables.

I'm sorry but I can't make sense of what you write here. In addition I'm not 
sure what you mean because there are two main interpretations.

If you mean that user defined Python routines are mutable, yes that's right, but 
not what I was talking about (which you can easily see by checking whether it 
makes sense in context; it doesn't).

If you mean that a routine of itself is a variable, no it isn't, but the name of 
a routine, like "foo" in

    def foo: print( "uh" )

or "bar" in

    bar = lambda: print( "oh" )

is a variable, per the language specification's definition quoted above (and 
also by any reasonable meaning of "variable"!).

The meaning of "variable" for Python terminology is specified by the language 
specification, as quoted above: a variable is a name.


[snipped rest, irrelevant]


Cheers & hth.,

- Alf