Re: Var-free programming (slightly off-topic)

[address@hidden (Jeremy Hylton)]

>>>>> "DW" == Dan Weinreb <dlw@exceloncorp.com> writes:

  DW> 5. I'll cross the line from language to implementation (hit me
  DW>       hard on the head, Simon!): it needs to provide a rapid
  DW>       execution environment.

  DW> I think that needs to be said more carefully.  It could easily
  DW> be interpreted as "programs must execute quickly".  Python, I
  DW> was told, doesn't even try to do this.

I hope I didn't oversell the point at the workshop :-).

Performance is not a top priority for the Python implementation.  We
use a bytecode interpreter, so at some level it's quite fair to say we
don't even try.  But we do hope to have a bytecode interpreter that
provides good perfomance subject to other higher priority constraints
like portability and correctness.

Two examples illustrate the tradeoffs we tend to make.

There is a lot of careful engineering in the implementation of the
dict and list builtin datatypes.  The implementations of these types
have changed frequently as Python has evolved.  This happened because
Python programs tend to use these datatypes a lot, and dictionaries
are used to implement instance and class namespaces.  

    (There are some long comments in the implementation, the file
    Objects/dictobject.c that discuss some of the interesting and
    subtle issues.

    http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/dictobject.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
    )

There are a number of checks we need to make to avoid core dumps when
programmers make stupid mistakes.  It is a goal to provide Python
exceptions with tracebacks instead of core dumps wherever possible.
The sort() method on builtin lists needs to guard against objects that
have buggy comparison methods, __cmp__(), that don't give consistent
answers.  Printing and comparing recursive data structures requires a
bunch of extra checks to make sure we don't blow the stack.  

All these checks tend to make the interpreter slower, at least for
some specific set of applications.

Jeremy