Functional languages vs. hybrids (was Re: How does Ruby compare to Python?? How good is DESIGN ofRubycompared to Python?)

Paul Prescod paul at prescod.net
Sat Feb 28 17:44:14 CET 2004


Joe Mason wrote:

>...
 > Down in the depths of the compiler, the simplest way to
 > implement (C-style) functions is just to total up all the
 > parameters and local space it will need and lay out a
 > stack frame.

We're talking about Python and the Python compiler generates Python 
bytecodes, not machine code!

> ...hybrid languages like Python and Ruby and Java and C#, then.  It's
> the combination of first-order functions *and* side effects that kills
> you.  (I don't know enough Java/C# to know if they have nested functions
> and "function pointers" or equivalent - it actually wouldn't surprise me
> if Java doesn't.)

Python function calling was never even remotely close to machine 
function calls for a variety of reasons (primarily the fact that we're 
talking about an interpreter rather than a compiler).

You may well be right that Python _would_ pay a cost for nested 
functions if its function model was not already substantially more 
complicated, sophisticated and expensive than C's. But there are all 
sorts of reasons that Python function calls are slow and I frankly think 
that nested scopes are the least of them:

  * Python functions use a stack that is different than the C stack 
(that's why stackless is even possible)

  * Python functions have complicated calling conventions (varargs, 
optional args, keyword args)

  * Python functions are called through a protocol that supports other 
types of "callables"

  * Python integers etc. must be unboxed after the function call to do 
anything useful with them

All of these performance-sucking features were in Python long before 
nested functions.

  Paul Prescod






More information about the Python-list mailing list