«

I finally finished (draft), I believe!, chapter 2...

Chapter 1 gets the reader up & running, i.e. it's "Hello, world!", basic tool
usage, without discussing anything about programming really. One reaction to
this chapter, based on the two example programs in it, was that it wasn't
gradual and slow enough; hey, those examples are far too advanced, and
unexplained! But that reader misunderstood: the progression is actually *slower*
than one might expect. This chapter is only about tool usage. I.e., it's about
getting those programs running, for the reader who can't rely on teachers or
fellow students or, as Kernighan & Ritchie put it, "your local guru" (IIRC).

Chapter 2 is about Basic Concepts (of programming). It's the usual: variables,
basic types and arrays, loops, decision, routines, classes, events, although not
presented in that order. I make heavy use of complete, concrete examples, many
of them graphical, and everything is in support of what's actually needed for
such concrete examples. The intent is to enable the reader to experiment and try
things out -- since the only way to really learn is by doing! As best I could
I've labored to apply this minimalism also to the Python language, using only a
"minimal" subset (to the degree of not even introducing boolean ops ).

Chapter 3 will, by my current plan, delve into the Python language and such
things as how integers and floating point works on the inside, and that includes
those in chapter 2 not even mentioned boolean operations. One important issue,
introducing exceptions, and in support of that, type hierarchies. After chapter
3 I have only much vaguer notions about what to introduce in what order, but a
main issue, assuming that I go on with this writing, will be to apply and teach
methodology all the way, integrated into the examples and text.

A table of contents + chapters 1 and 2 is available in PDF format at Google Docs, at

<url: http://tinyurl.com/programmingbookP3>

Comments are very welcome!

Re comments: there are two deviations from current Python practice in chapter 2.
First, that I use spaces inside argument parentheses, which makes the code more
readable when one gets used/trained to it because it gives the eye more direct
information (with some training visual structure can be processed unconsciously
& effortlessly, but purely logical structure has to be processed analytically).
The second deviation is that since most names are constants, I do not follow PEP
8's recommendation to use uppercase names of constants. 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 and in particular routine names are usually
constants, absolutely not meant to be modified, but it would be silly to UC...

So both these two deviations from Python practice are /intentional/, since this
is a book about programming, not about Python the language & how to conform to
idiosyncratic language-specific conventions.

But, if there are other deviations from Python practice I'd be very glad to hear
of it! I'm very hopeful that any such convention deviations can be fixed.


Cheers,

- Alf

> The second deviation is that since most names are constants,

Really? Does that mean you don't use literals, to save the time
required to convert them to integers? Isn't that done at compile
time?

So, instead of doing the Collatz Conjecture as

while a>1:
f = gmpy.scan1(a,0)
if f>0:
a = a >> f
else:
a = a*3 + 1

You would do this?

zed = 0
one = 1
two = 2
twe = 3
while a>one:
f = gmpy.scan1(a,zed)
if f>zed:
a = a >> f
else:
a = a*twe + one

Does this really save any time?

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.

In that case, you DO want to use constants as opposed to literals:

ZED = gmpy.mpz(0)
ONE = gmpy.mpz(1)
TWO = gmpy.mpz(2)
TWE = gmpy.mpz(3)
while a>ONE:
f = gmpy.scan1(a,0) # int used here, so it can be a literal
if f>ZED:
a = a >> f
else:
a = a*TWE + ONE

And yes, the time savings can be tremendous, especially when 'a'
has over 50,000 decimal digits.

.. I do not follow PEP
> 8's recommendation to use uppercase names of constants. In fact almost no Python
> code does,

Mine does when I use gmpy. Otherwise, the notion that "most names
are constants" is generally false.

* Mensanator:
>> The second deviation is that since most names are constants,
>
> Really? Does that mean you don't use literals, to save the time
> required to convert them to integers? Isn't that done at compile
> time?
>
> So, instead of doing the Collatz Conjecture as
>
> while a>1:
> f = gmpy.scan1(a,0)
> if f>0:
> a = a >> f
> else:
> a = a*3 + 1
>
> You would do this?
>
> zed = 0
> one = 1
> two = 2
> twe = 3
> while a>one:
> f = gmpy.scan1(a,zed)
> if f>zed:
> a = a >> f
> else:
> a = a*twe + one

That seems to have no relation to what you quoted / responded to.

On the other hand, if there is some specific rôle played by the 3 above, where
some other value (like e.g. 5) might be used instead, then a self descriptive
name for that rôle might be good.

Such reasonable naming (not what you did above) then allows easier modification
of and makes it easier to understand the code.

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.


> Does this really save any time?

If by "it" you mean the silly naming, no it doesn't.

On the contrary, it wastes time, both for writing the code and reading it.

Generally, IMO, think about the clarity of your code. If naming something
increases clarity, then name the thing. If it doesn't increase clarity, don't.


> 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.
>
> In that case, you DO want to use constants as opposed to literals:
>
> ZED = gmpy.mpz(0)
> ONE = gmpy.mpz(1)
> TWO = gmpy.mpz(2)
> TWE = gmpy.mpz(3)
> while a>ONE:
> f = gmpy.scan1(a,0) # int used here, so it can be a literal
> if f>ZED:
> a = a >> f
> else:
> a = a*TWE + ONE
>
> And yes, the time savings can be tremendous, especially when 'a'
> has over 50,000 decimal digits.

Yeah, good point. Few languages have compile time evaluation of logically
constant expressions. 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.


> . I do not follow PEP
>> 8's recommendation to use uppercase names of constants. In fact almost no Python
>> code does,
>
> 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". The problem with Python, as
Google noted, is that the language is so excessively dynamic: even names of
routines are variables, and there /are/ no named user defined constants except
logically, in the programmer's mind. 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.

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 think for such constants exported by modules it's a good idea to at least
provide uppercase names so as conform to very firmly established convention.
There might even be tools that rely on that convention. But for application code
the uppercase names are just distracting, and they don't help you...


Cheers & hth.,

- Alf

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

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

* 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

* 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

Steven D'Aprano <> writes:

> CPython 2.5 and on has a keyhole optimizer that replaces many constant
^^^^^^^
Shouldn't that be peephole?

> expressions with pre-computed values.

And that's called constant folding.

Unless I misread your post (or have been out of touch with compiler
building too long)

--
John Bokma

Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/

On Fri, 18 Dec 2009 15:26:05 -0800, Mensanator wrote:

>> The second deviation is that since most names are constants,
>
> Really? Does that mean you don't use literals, to save the time required
> to convert them to integers? Isn't that done at compile time?
>
> So, instead of doing the Collatz Conjecture as
>
> while a>1:
> f = gmpy.scan1(a,0)
> if f>0:
> a = a >> f
> else:
> a = a*3 + 1
>
> You would do this?
>
> zed = 0
> one = 1
> two = 2
> twe = 3
> while a>one:
> f = gmpy.scan1(a,zed)
> if f>zed:
> a = a >> f
> else:
> a = a*twe + one
>
> Does this really save any time?

There are some people who might argue that using *any* magic constants in
code is wrong, and that *all* such values should be declared as a
constant.

It's easy to take the mickey out of such an extreme position:

zed = 0 # in case we need to redefine 0 as something else
one = 1 # likewise
two = 3 # changed from 2 to 3 to reflect the end of the Mayan calendar

# The following is guaranteed to pass unless the world is ending.
assert one+one == two-zed



--
Steven

Mensanator wrote:
> Really? Does that mean you don't use literals, to save the time
> required to convert them to integers?

I think all he means is that when he *does* use a named
constant, he spells it in lower case rather than upper
case, e.g. 'twopi' rather than 'TWOPI'.

I don't think there's anything much wrong with that. It
can be useful sometimes to visually distinguish constants
from variables, but it's not a necessity. Also the all-
uppercase convention isn't the only way to do that -- it's
a C-ism that isn't universally followed in Python. An
alternative often used is just to uppercase the first
character. Python itself uses that for many of its
built-in constants, such as None, True, False.

Arguing that functions are usually constants and should
therefore have uppercase names is missing the point --
everyone expects them to be constant anyway, so there's
no need for a typographical convention to indicate that.
In the rare cases where they're not constant, they can
usually be named in a way that makes this obvious.

(And BTW, looking up a global name is *slower* than using
a literal. Although a local name is probably about the
same speed as a literal, as they're both array accesses.)

--
Greg