Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: @PyNoobs: The Fundamental Five Built-in Functions, and Beyond!
Date: Tue, 26 Jul 2011 22:53:25 -0400
References: <d480e736-6b4a-42cf-85da-5563c016c711@q11g2000yqm.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
In-Reply-To: <d480e736-6b4a-42cf-85da-5563c016c711@q11g2000yqm.googlegroups.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1523.1311735220.1164.python-list@python.org>
Lines: 86
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:10366

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