Req. comments on "first version" ch 2 progr. intro (using Python 3.x in Windows)

[Jon Clements]

On Nov 9, 5:22 pm, "Alf P. Steinbach" <al... at start.no> wrote:
> * Jon Clements:
>
>
>
> > On Nov 9, 4:10 pm, "Alf P. Steinbach" <al... at start.no> wrote:
> >> Chapter 2 "Basic Concepts" is about 0.666 completed and 30 pages so far.
>
> >> It's now Python 3.x, and reworked with lots of graphical examples and more
> >> explanatory text, plus limited in scope to Basic Concepts (which I previously
> >> just had as a first ch 2 section  --  but there's rather a lot of concepts!).
>
> >> I think it's wise to invite comments even when it's not 100% completed. First,
> >> because as opposed to ch 1 there is quite a bit of code here, and since I'm a
> >> Python newbie I may be using non-idiomatic constructs, not to mention doing
> >> worse things. :-) Second, because comments in general can improve the text.
>
> >> Contents:
>
> >> 2.1 Super-basic concept: why programming is not DWIM.   1
> >> 2.2 Reported errors.    4
> >> 2.2.1   Case-sensitity. 4
> >> 2.2.2   Syntax / compilation errors.    4
> >> 2.2.3   Runtime errors / crashes.   5
> >> 2.3 A programming exploration tool: turtle graphics.    6
> >> 2.4 Naming things.  8
> >> 2.4.1   Naming actions: routines.   8
> >> 2.4.2   Naming data part I: variables.  11
> >> 2.4.3   Naming data part II: routine arguments. 13
> >> 2.5 Controlling the flow of execution.  14
> >> 2.5.1   Repeating actions automatically: loops. 14
> >> 2.5.2   Basic comparisions & boolean values.    16
> >> 2.5.3   Interlude I: a function graph program / about types.    17
> >> 2.5.4   Automated action choices.   21
> >> 2.5.5   Value-producing (function-like) routines.   23
> >> 2.5.6   Interlude II: a graph with zeroes marked / about program structure. 26
> >> 2.5.7   Dynamically nested actions: recursive routines. 28
> >> 2.6 Objects.     [Not started on this] 31
> >> 2.7 Collections.    [Not started on this] 31
>
> >> In Google Docs (both chapters available here):
>
> >>      <url:http://preview.tinyurl.com/ProgrammingBookP3>
> >>      Formats: PDF
>
> >> Cheers,
>
> >> - Alf
>
> > Well, you may not like it, but it is perfectly acceptable and indeed
> > promoted to use CONSTANT_VAR_NAMES. You're almost discouraging the use
> > of a well understood and oft-used idiom. I they're a lot of them, you
> > generally have a settings module, that just lists all of the
> > 'constants' (.h files effectively).
>
> Yeah, I thought of that angle so I emphasized 'programs'.
>
> As it happens about half or more of the variables in the examples are constants.
>
> All uppercase convention for that would be ugly to me. :-)

Okies, maybe introducing the fact that lots of 'programs' often have
constants, which are quite often settings or whatever and they would
use the uppercase notation (and if numerous, in a separate module).
Also maybe you can introduce the fundamental idea of a 'namespace',
maybe something like:

class const:
    pi = 3.14
    name = 'Alf'
    language = 'Python'

or whatever, then reference const.<var> ?

I'm not 100% sure I'm keen on this idea, but it's an option you can
consider at least. Introduces a couple of bits that may be discussed
later, but I'd be a little scared that people would start thinking
'const.' was something magical.

>
> > "Technically line_length is a variable"...: No - it's a name that
> > binds to an object that happens to be an integer. You've participated
> > in discussions re: this. Similarly 'number_of_apples =
> > number_of_apples + 1' is not an assignment ;)
>
> Ah, you're kidding.
>
> Probably.
>
> Anyways, that's the terminology employed by the language reference, and even if
> it wasn't I'd use it because this is primarily introduction to programming in
> general, where Python just happens to be the vehicle; thus, language independent
> terminology preferred (e.g., I use "routine" instead of C/Python "function").
>
> > It's nit-picky and I
> > realise you're trying to keep it simple, but as it's meant for new
> > programmers to the Python language, then introduce them to Python's
> > way of "variables", they'll thank you for it later... (or run
> > screaming, or start another thread here...)
>
> Yeah, good point, thanks!
>
> But it will have to wait till I get down into details... ;-)
>

Fair enough. It would be nice though to cover stuff like:

a = [1,2,3]
b = a

- b is not a *copy* of a
- b is not a *reference* to a
- b just happens to be another name for the list object.

And stuff about mutable/immutable: it would certainly help with a lot
of gotcha's.

> > I've never seen/heard != described as "different from"; what's wrong
> > with "not equal to"?
>
> Thanks!
>
> > And why no mention of 'not' (should be mentioned
> > with booleans surely?).
>
> Again, I'll discuss that later. It's just too much to bring up. Most of my work
> with this has been to pare down to essentials and *remove* stuff I'd written.
>

Well, should you re-write != as "not equal to", it wouldn't hurt to
mention a little later that not False is True and vice versa...

> > That's as far as I've got; might get around to reading more later...
>
> > Cool tree at the end :)
>
> Thanks!
>
> Cheers,
>
> - Alf

Cheers,

Jon.