Comments requested: brief summary of Python

[Paddy McCarthy]

adamba at gte.net (Adam Barr) wrote in message news:<ce782195.0402232218.6e64177c at posting.google.com>...
> For a book I am working on, I have written a brief (9 page) summary
> of Python. The intent of this is that an experienced programmer who
> did
> not know Python would be able to get enough information to read and
> understand Python programs. It is not meant to be a 100% complete
> summary of the language, but everything in there should be correct.
> 
<<SNIP>>
> The file is at
> 
> http://www.proudlyserving.com/language/python.pdf
> 
> I have written similar summaries for other languages and will
> hopefully post them (with a virtually identical message) in the
> appropriate newsgroups in the next few days.
> 
> Thank you.
> 
> - Adam Barr
> adamba at gte.net

Hi Adam.
First off, Congratulations, I read the Perl and Python PDFs and saw
nothing that I thought you had purposefully written to start a
language war.

I'll confine my comments to the Python PDF  (so I don't re-kindle any
wars :-).


I made a few notes whilst reading through your file that I will add at
the end but I can't help but think that your description of Python is
for using it in an un-Pythonic manner (as others have stated). Whilst
you may explain enough Python for someone to follow any examples you
have in your book, I fear that the algorithms and language structures
that you may use would not be those favoured by Python programmers.
I'll touch on some of these areas later.

The notes are on points roughly in the order given in your document.

1) You mention variable for i and then state that variables cantchange
their type once set. In Python we like to call the 'i' in your example
a name and say it points to an object and that the *object* has a type
and the type of that, individual object will not change. The name can
be made to point to another object that could have a different type
but the type of the first object is not changed.

2) When you introduced slices, slices can have a step as well as a
start and stop.

3) When introducing lists and tuples you want to also explain
im/mutability, i.e. a list type object is said to be mutable
(changeable in some ways), because the individual elements of a list
may be changed on the same list object. A tuple objects elements
cannot be changed (although you may generate a new tuple object based
on an the elements of the first tuple).

3b) You could add that lists and tuples are *ordered* sets of
elements.

4) When you introduce len you might want to add that it returns the
'length' of most collection type objects e.g lists,tuples, and
dictionarys

5) If you define im/mutability you can then say that dictinary keys
can be any immutable object such as integers, strings, tuples but not
lists

6) You didn't mention document strings!  When you download Python for
a lot of environments it will come with editors and debuggers that can
use document strings to aid in your coding. The pydoc utility can be
used, with document strings to document (HTML txt) and present
(inbuilt web server and search capability), the documentation for your
program.

7) In your mention of modules you should note that there is an
extensive, well documented, high quality library of modules that comes
as part of the Python installation ready to be included. (Whoops I
started selling Python there :-)


Hey, all that, and not one unkind word about Perl. I'll have to pinch
myself :-)

Paddy.