Re: @PyNoobs: The Fundamental Five Built-in Functions, and Beyond!
On Jul 26, 9:53 pm, Terry Reedy tjre...@udel.edu wrote: On 7/26/2011 8:01 PM, rantingrick wrote: 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. Actually you have to be careful of objects too. Consider this: py import Tkinter py root = Tkinter.Tk() py print root . py print repr(root) Tkinter.Tk instance at 0x02BDC4E0 py label = Tkinter.Label(root) py print label .46012656 py print repr(label) Tkinter.Label instance at 0x02BE18F0 ...as you can see, if someone overrides __str__ you can get some very confusing return values from a naked print(obj) -- which simply calls obj.__str__() under the covers. -- 5. id() -- http://docs.python.org/py3k/library/functions.html#id [...} 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. Yes this one can cause some major confusion to newcomers. I wonder if python should throw a warning anytime you call id() on an immutable type. py a = 12345 py id(a) 45313728 py b = 12345 py id(b) 45313728 That first call to id should have thrown a warning: Traceback (most recent call last): File pyshell#5, line 1, in module id(a) Warning: Comparing ids of immutable types is unreliable! and an Exception if someone tries an assertion! py assert id(a) != id(b) Traceback (most recent call last): File pyshell#6, line 1, in module assert id(a) != id(b) Exception: Cannot compare immutable types! -- http://mail.python.org/mailman/listinfo/python-list
Re: @PyNoobs: The Fundamental Five Built-in Functions, and Beyond!
Beyond! On 27/07/11 02:01, rantingrick wrote: -- 1. help() -- -- 2. dir() -- Pro tip: the IPython enhanced Python shell makes these two even more amicable. -- 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. Also handy: the pprint stdlib module to pretty-print complex structures. http://docs.python.org/py3k/library/pprint.html -- 5. id() -- This reminds me of something I did last year. Some of you might recall. http://blog.jollybox.de/archives/62-python-swap (Word of warning: bad idea. Very, very bad idea. Still, potentially amusing. Kind of like blowing up a giant hydrogen-filled baloon.) -- http://mail.python.org/mailman/listinfo/python-list
Re: @PyNoobs: The Fundamental Five Built-in Functions, and Beyond!
On Wed, 27 Jul 2011 10:01 am 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. Rick, this is excellent work. If you did more of this sort of thing and less ranting, you would be far more respected and much less likely to be kill-filed. You've just earned yourself a retroactive Get Out Of Kill-File card. Don't make me regret it. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: @PyNoobs: The Fundamental Five Built-in Functions, and Beyond!
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 -- http://mail.python.org/mailman/listinfo/python-list
