Return to Home Page
      Blog     Consulting     Seminars     Calendar     Books     CD-ROMS     Newsletter     About     FAQ      Search
 

Thinking in Python

A book that will be written

Powerpoint slides from my closing keynote presentation at the Ninth International Python Conference. HTTP download

Why is Python great, and why should you switch? Eric Raymond, the insightful author of The Cathedral and the Bazzar, had a nearly identical experience coming to Python as I had, which he eloquently describes here.

Please don't ask me when any of this stuff will be available. I currently have no idea when it will evolve, how much I'll work on it, etc.

To stave off the many emails that I have been receiving that suggest I consider writing a book titled Thinking in Python: yes, I've definitely been planning to do it. Considering that Python is my language of choice for virtually all my own programming projects, my research into the language is continuing apace.

However.

Right now it's still a gleam in my eye. The ideas continue to form as I learn more about the language, and I'll stick notes on this page which will be unstructured and by no means a book, but notes and things I am considering covering in the book. Also, whenever we start giving some kind of seminar (this will be announced here, and on the mailing list, so please don't ask when), I will get a better idea of the way people learn the language. Here are my current thoughts:

  • I don't intend to duplicate the approach of existing Python books like Learning Python by Lutz & Ascher (O'Reilly, 1999), which I think does a fine job of teaching the language to programmers.

  • Currently, I believe that this will be an intermediate-level book, initially a translation of "Thinking in Patterns" from Java to Python, where I think the concepts will be much clearer and simpler.

  • For people just learning to program, I find that the online book How to Think Like a Computer Scientist (Python) seems good, and there's an interactive online version

  • The print book Learn to Program Using Python does quite a decent job (this is also available online).

  • You can find a nice introduction to Python which compares it to Perl here.

  • You can find lots of organized links to python information on cetus.

  • Here is a nice list of articles (including some intermediate-level material called "Charming Python," (published as a column in IBM DeveloperWorks by Dr. David Mertz.

  • For information about new developments in Python, see the Daily Python URL.

  • For weekly summaries of what's going on with Python, subscribe to Doctor Dobb's Python-URL by sending an email to claird@neosoft.com to subscribe. Mention "Python-URL!".

  • Right now, I think that my book will be focused on object-oriented programming in Python (along with the use of some of the more interesting Python features that might be ignored by the casual programmer) rather than trying to teach the breadth of the language. This way it can also be a general introduction to OOP.

  • The book will be up on the web site as it develops. There's nothing available now, since there's nothing to post.

  • There may be a MultiMedia CD ROM before there is a printed book.

  • Information about Python:

  • Main Site: www.python.org (includes the free downloads for the installers for many platforms).
  • Executive summary, brief introductions, Comparison with other languages, etc.
  • Python performance tips

  • Notes

    As an experiment, I will add notes here as I discover things of interest about Python that I may want to include in the book.

    Exception Handling

    When writing CGI's in Python, you don't get any feedback to the html page when they fail. However, exceptions can be redirected to give information, but I didn't know how to get more valueable information without writing a bunch of different try blocks, so I asked Fredrik Lundh for some way to write the same line of exception handling code everywhere, and to produce more complete information:

    ...My goal would be to be able to paste in the identical line of code everywhere, without having to edit it for the particular file name and function name.

    Fredrik: Use the traceback module. I usually use something like this:

    import traceback
    
    def foo():
      try:
          print [][0]
      except Exception, v:
          traceback.print_exc()
    

    This prints the entire traceback to sys.stderr.

    You could also create your own traceback utility, and put it in a suitable helper module.

        import traceback, sys
    
        def exception():
            try:
                type, value, tb = sys.exc_info()
                info = traceback.extract_tb(tb)
                filename, lineno, function, text = info[-1] # last line only
                print "%s:%d: %s: %s (in %s)" %\
                      (filename, lineno, type.__name__, str(value), function)
            finally:
                type = value = tb = None # clean up
    
    def foo():
      try:
          print [][0]
      except Exception, v:
          exception()
    

    which prints something like:

    test.py:15: IndexError: list index out of range (in bar)
    

    Kevin Altis suggested this:

    If you haven't already done so, check out cgitb at http://web.lfw.org/python/.

    Since pydoc.py and inspect.py are included in the Python 2.1 distribution, you should only need cgitb.py. A sample dump is at http://web.lfw.org/python/test4.html.

    Even if you leave your current CGI traceback suggestion, a pointer to cgitb would probably help a lot of people.


    Creating C/C++ Extension Modules

    The simplified wrapper and interface Generator (SWIG) at http://swig.sourceforge.net is designed to ease the process. I haven't done this yet, but I want to. Creating extension modules is central to Python's power, because it potentially allows you to use python (by increasing performance in bottlenecks) rather than having to change over to another language. It also allows you to obscure code that you might want to keep proprietary, which is an issue for many people.


    A Quantitative Analysis Library

    The QuantLib project (http://quantlib.org) is aimed at providing a comprehensive software framework for quantitative finance. QuantLib is a free/open source library for modeling, trading, and risk management in real-life.

    QuantLib is written in C++ with a clean object model, and is then exported to different languages such as Python and Ruby. Bindings to other languages (including Java), and porting to Excel/Gnumeric, Matlab/Octave, S-PLUS/R, COM/CORBA/SOAP architectures, FpML, are planned for the near future.

    Appreciated by quantitative analysts and developers, it is intended for academics and practitioners alike, eventually promoting a stronger interaction between them. QuantLib offers tools that are useful both for practical implementation and for advanced modeling, with features such as market conventions, yield curve bootstrapping, solvers, PDEs, Monte Carlo, exotic options, VAR, and so on. More complex tools such as interest rate models are next on the to-do list.

    Please consider joining one of the available mailing lists.
    quantlib-announce
    quantlib-dev
    quantlib-users
    quantlib-cvs


    Frederik Lundh's Resources

    See here for a number of resources; the Guide To The Standard Python Library is exceptionally useful, and can be found at Fatbrain.


    An idiom for concatenating strings

    (from Frederik; a nice little test to see how many things you understand about Python. Look everything up and figure it out — should give you a nice warm feeling when you're done)
      cs = lambda *args: ''.join(map(str,args))
    
    Example:
      print cs("X=",x," Y=",calc_y(x))
    

    Why Python Works

    The Python Way

    By Tim Peters
    (Who I assume will speak up if he doesn't want me to post this)

    • Beautiful is better than ugly.
    • Explicit is better than implicit.
    • Simple is better than complex.
    • Complex is better than complicated.
    • Flat is better than nested.
    • Sparse is better than dense.
    • Readability counts.
    • Special cases aren't special enough to break the rules.
    • Although practicality beats purity.
    • Errors should never pass silently.
    • Unless explicitly silenced.
    • In the face of ambiguity, refuse the temptation to guess.
    • There should be one-- and preferably only one --obvious way to do it.
    • Although that way may not be obvious at first unless you're Dutch.
    • Now is better than never.
    • Although never is often better than *right* now.
    • If the implementation is hard to explain, it's a bad idea.
    • If the implementation is easy to explain, it may be a good idea.
    • Namespaces are one honking great idea -- let's do more of those!

    Favorite quotes

    (I fell in love with Perl for a couple of months, and explored all the (dark) corners. It's what eventually drove me to Python).

    Python is executable pseudocode. Perl is executable line noise.

    Perl is like vice grips. You can do anything with it, and it's the wrong tool for every job.

    Perl is worse than Python because people wanted it worse. Larry Wall (Creator of Perl), 14 Oct 1998

    I would actively encourage my competition to use Perl.Sean True, 30 Mar 1999

    The secret to good performance is to prototype and prototype, then code the bottlenecks in a faster language. The secret to large systems is to prototype and prototype, until you've got clean separation of the system into managable pieces, then code in whatever language most suits the need of each piece.Gordon McMillan, 15 Dec 1999

    "Complexity" seems to be a lot like "energy": you can transfer it from the end user to one/some of the other players, but the total amount seems to remain pretty much constant for a given task.Ran, 5 Mar 2000

    Someone even went to the trouble of creating a module that allows you to write Perl in Latin syntax, here. I maintain that this idea wouldn't even occur to Pythonistas, although it is a logical place to go in Perl because of the arcane and historically-rooted syntax.


    Cover ideas

    A grid of dropped-out line art of tractor photos, water colored like those I did in "Thinking in C++, 2nd edition


    How to Escape from a Python

    "Unlike poisonous snakes, pythons and boas kill their prey not through the injection of venom but by constriction; hence these snakes are known as constrictors. A constructor coils its body around its prey, squeezing it until the pressure is great enough to kill.

    "Since pythons and boas can grow to be nearly twenty feet long, they are fully capable of killing a grown person, and small children are even more vulnerable. The good news is that most pythons will strike and then try to get away, rather than consume a full-grown human.

    1. Remain still. This will minimize constriction strength, but a python usually constinues constricting well after the prey is down and not moving.
    2. Try to control the python's head and try to unwrap the coils, starting from whichever end is available.
    From The Worst-Case Scenario Survival Handbook by Joshua Piven and David Borgenicht, Chronicle Books 1999.
    Search     Home     WebLog     Consulting     Seminars     Calendar     Books     CD-ROMS     Newsletter     About     Contact     Site Design     Server Maintenance     Powered by Zope
    ©2007 MindView, Inc.