Easy questions from a python beginner

[Steven D'Aprano]

On Thu, 22 Jul 2010 22:47:11 -0400, wheres pythonmonks wrote:

> Thanks for pointing out that swap (and my swap2) don't work everywhere
> -- is there a way to get it to work inside functions?

Not in CPython. In IronPython or Jython, maybe, I don't know enough about 
them. But even if you got it to work, it would be an implementation-
dependent trick.

[...]
> I always think that it is the language's job to express
> my thoughts...  

Ha, no, it's the language's job to execute algorithms. If it did so in a 
way that is similar to the way people think, that would be scary. Have 
you *seen* the way most people think???

*wink*


> I don't like to think that my thoughts are somehow
> constrained by the language.


Whether you "like" to think that way, or not, thoughts are influenced and 
constrained by language. While I don't accept the strong form of the 
Sapir-Whorf hypothesis (that some thoughts are *impossible* due to lack 
of language to express them, a position which has been discredited), a 
weaker form is almost certainly correct. Language influences thought.

Turing Award winner and APL creator Kenneth E. Iverson gave a lecture 
about this theme, "Notation as a tool of thought", and argued that more 
powerful notations aided thinking about computer algorithms.

Paul Graham also discusses similar ideas, such as the "blub paradox". 
Graham argues that the typical programmer is "satisfied with whatever 
language they happen to use, because it dictates the way they think about 
programs". We see this all the time, with people trying to write Java in 
Python, Perl in Python, and Ruby in Python.

And Yukihiro Matsumoto has said that one of his inspirations for creating 
Ruby was the science fiction novel Babel-17, which in turn is based on 
the Sapir-Whorf Hypothesis.



> The truth is that I don't intend to use these approaches in anything
> serious.  However, I've been known to do some metaprogramming from time
> to time.
> 
> In a recent application, I pass in a list of callables (lambdas) to be
> evaluated repeatedly.

Are you aware that lambdas are just functions? The only differences 
between a "lambda" and a function created with def is that lambda is 
syntactically limited to a single expression, and that functions created 
with lambda are anonymous (they don't have a name, or at least, not a 
meaningful name).


> Clearly, a superior solution is to pass a single lambda that returns a
> list.

I don't see why you say this is a superior solution, mostly because you 
haven't explained what the problem is.


> [Less function call dispatches] 

How? You have to generate the list at some point. Whether you do it like 
this:

functions = (sin, cos, tan)
data = (2.3, 4.5, 1.2)
result = [f(x) for f, x in zip(functions, data)]

or like this:

result = (lambda x, y, z: return (sin(x), cos(y), tan(z))
    )(2.3, 4.5, 1.2)

you still end up with the same number of function calls (four). Any 
execution time will almost certainly be dominated by the work done inside 
the lambda (sin, cos and tan) rather than the infrastructure. And unless 
you have profiled your code, you would be surprised as to where the 
bottlenecks are. Your intuitions from Perl will not guide you well in 
Python -- it's a different language, and the bottlenecks are different.


> However, it might be more
> efficient to avoid the function call overhead completely and pass-in a
> string which is substituted into a string code block, compiled, and
> executed.

See, that's *exactly* what I mean about intuitions. No no no no!!! Using 
exec or eval in Python code is almost certainly a *pessimation*, not an 
optimization! I expect this will be an order of magnitude slower to 
parse, compile and execute a string than it is to execute a function. 
Using exec or friends to avoid the overhead of function calls is like 
pushing your car to work to avoid the overhead of having to get in and 
out of the car.

But of course, don't take my word for it. Write your code and profile it, 
see where the bottlenecks are. I might be wrong.



-- 
Steven