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

Kenneth Manheimer (
Mon, 20 Jun 1994 21:59:30 GMT

Thanks much, tim. I've incorporated most, if not all, of your
corrections and suggestions. I think there are a few items i need to
follow up upon.

> 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:


(Say, what's the deal with the overlap in the ref manual and the lib ref
manual? It seems like the lib ref manual provides more up-to-date and
exact details on the things it does cover, though i may have that
impression because i went through the lib ref after i'd digested the
regular ref...)

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

I was referring to the fact that successive conditions are evaluated
depending on the values of preceeding ones - is that short-circuiting?
I think i've heard it referred to both ways, but that may just be me
hallucinating again...-)

> 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.

That makes sense - do you think it ought to be explicitly articulated in
the cheat sheet? Do you have suggestions how i might fit it in?

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

I may want to put this in my 'useful hints and idioms' section.

> > . } 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).

This is a crucial point. I think i got much more clear about it from
reading the lib ref manual, and have tried to express it clearly (but
concisely). How does this look?

Dictionaries: {key1: val1, key2: val2, ...}

- built-in types as keys must be unalterable: obj & all contents immutable
- User-defined classes as keys must have __hash__() and __cmp__() methods
- TypeError is raised if key not acceptable
- KeyError is raised if reference made using non-existent key
- key types may vary (contrary to the ref man)