Re: A first draft python fact sheet, extracted from the Python Ref Manual

Tim Peters (
Thu, 16 Jun 94 00:12:16 -0400

Very nice summary! Just suggesting some changes here, in some cases
because the docs you started from are out of synch with the current
incarnation of the language:

> Illegitimate Tokens (only valid in strings): @ $ " ?

Double quote no longer belongs in that list.

> < == > <= <> != >=, is [not], [not] in: __cmp__(self)

+ defaults to comparision by object id if __cmp__ not defined.

> operators: 'not', 'and', 'or'; binary ones shortstop

> . } Code Block scopes (ns = name space, cb = containing block)
> Code block type Global ns Local ns Notes
> --------------- --------- -------- -----
> Module module ns same as global ns
> Script __main__ ns same as global ns
> Interactive cmd __main__ ns same as global ns
> Class def global ns of cb new ns
> Function body global ns of cb new ns
> 'exec' string global ns of cb local ns of cb (or args)
> 'eval' string global ns of caller local ns of caller (or args)
> 'execfile' file global ns of caller local ns of caller (or args)
> 'input' expr global ns of caller local ns of caller

While the "Global ns" column is accurate, it boils down to just this:
Today, every piece of code executes in some module, and the global ns for
the code is simply the module's namespace; the "global ns of cb/caller"
clauses always trace a chain back up to "Module", "Script" or
"Interactive cmd". The only exception is when the global ns is
explicitly overridden via argument to exec/eval/execfile.

> . } formal params

Worth mentioning the "*" arb-#-of-args and "=" default-arg-value

> Integers: -2^31 to 2^31 - 1; OverFlow error if bounds exceeded

Different parts of the docs disagree about this; the truth <wink> is that
it varies across machine. E.g., on a KSR machine Python ints are 64
bits. The real range is -sys.maxint-1 thru sys.maxint, inclusive.

Nit: (-sys.maxint-1)/-1 doesn't raise OverflowError, but should.

> . } Dictionaries (mutable): {key1: 'val1', key2: 'val2', ...}
> keys can be of any immutable types

Subtlety: Keys actually need to be hashable; immutable is neither
necessary nor sufficient. E.g., a tuple with a list component can't be
used as a key (so "top-level" immutability isn't sufficient), while
instances of any user-defined class that defines __hash__ and __cmp__
methods can be used as keys (so immutable isn't necessary).

Other: the quotes on 'val1' & 'val2' seem to imply that dict values must
be strings; just take 'em off.

minimally y'rs - tim

Tim Peters
not speaking for Kendall Square Research Corp