> 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:
Thanks!
(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)