On Nov 9, 5:22 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * Jon Clements:
>
>
>
> > On Nov 9, 4:10 pm, "Alf P. Steinbach" <al...@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.
--
http://mail.python.org/mailman/listinfo/python-list
