@PyNoobs: The Fundamental Five Built-in Functions, and Beyond!

[Terry Reedy]

On 7/26/2011 8:01 PM, rantingrick wrote:
>
>
> ============================================================
>   The "Fundamental Five" built-in functions
> ============================================================
> There are quite a few helpful built in functions provided to the
> python programmer however in my mind five of them are the most
> important to Python noobs. The "fundamental five" i call them. I
> believe you should not do anything with Python until you are
> completely familier with these five because most of the bugs and mis-
> understanding a new user experiences can be solved by using these five
> functions.
> ============================================================
>
> --------------------------------------------------
> 1. help()
> --------------------------------------------------
> http://docs.python.org/py3k/library/functions.html#help

help() with no args puts one into a special help mode to get info on 
various topics. help(obj) gets help on that object. I do not do the 
former much, but I increasingly use the latter.


> --------------------------------------------------
>   2. dir()
> --------------------------------------------------
> http://docs.python.org/py3k/library/functions.html#dir
>
> Python has name spaces. Name spaces are awesome. Name spaces keep code
> from clashing with other code. The dir() function will list the
> currently defined names in the current namespace. If your getting
> NameErrors check the name space with dir() function.

I use this constantly.
>
> --------------------------------------------------
>   3. repr()
> --------------------------------------------------
> http://docs.python.org/py3k/library/functions.html#repr
>
> Most new user think that printing an object to stdout is all they'll
> ever need. However when you call print -- or sys.stdout.write(object)
> -- you are only seeing a "friendly" version of the object.

This mostly applies to strings, which *do* have 2 printed versions.  It 
is occasionally very important for debugging string problems.

Printing collections alreays used repr() for members of the collection.

>
> --------------------------------------------------
>   4. type()
> --------------------------------------------------
> http://docs.python.org/py3k/library/functions.html#isinstance
>
> Ever had a TypeError? Ever had some object you were just sure was one
> type but is not behaving like that type? Then check it's type for
> Pete's sake! Even experienced programmers (of many languages) suffer
> from TypeErrors (be them subtle or not) because the type of an object
> cannot be inferred simply by looking at it's identifier. So when
> something ain't right, skip the tripe, and check the type!
>
> --------------------------------------------------
>   5. id()
> --------------------------------------------------
> http://docs.python.org/py3k/library/functions.html#id
>
> Ah yes, another source of frustration is the old "identical twin"
> syndrome (or in the worst forms; multiplicity syndrome!). Yes, on the
> surface that list of lists looks as if it contains unique elements
> HOWEVER you keep getting strange results. How are you going to find
> the problem? Hmm? Never fear my confused new friend, by comparing the
> ids of two objects you can know if they are actually the same or
> different. If the id is the same, the objects are the same.

This is the most dangerous of the builtins, as it sometimes mislead 
newbies into 'discovering' non-existent 'bugs'. The main point is that 
the id of immutable objects is mostly an irrelevant implementation 
detail, while the id of mutables may be critical. Lists of lists is a 
particular area where id() is really useful.

-- 
Terry Jan Reedy