The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

Michael Torrie torriem at gmail.com
Mon Mar 14 13:55:05 EDT 2016


On 03/14/2016 08:43 AM, BartC wrote:
> But how do you pass 'a' itself?
> 
> Perhaps you can say:
> 
>    f('a')
> 
> and f can do some sort of lookup, if it knows the caller's context, for 
> such a name and retrieve the value that way. But that's rather 
> heavy-handed, and f can't distinguish between a reference to a name, and 
> a string.
> 
> Unless maybe you wrap this up in a class and .... Well, you end up with 
> something that might emulate a name reference, but with so much 
> complexity and such overheads that it is not worthwhile.

Maybe, but I don't think so.  Is there really overhead in passing a
mutable object (a list) and working on it vs passing pieces of a list
one at a time? The lookup is the same, or maybe less.  In your example,
you have to do lookups for each item going into the function, and then
again when you assign the new values back into place in your source
list.  Passing the whole list into the function would seem to be faster.

> Yet, this is a feature I use extensively, far more often than I would 
> use mutable functions. And in fact it was used in the code for my jpeg 
> example, where in the Python I has to use a workaround (see below).

I think this is all just a matter of perspective. You seem convinced
that the C way is the only way to go from a performance standpoint. This
may or may not be true. There are certainly other paradigms. For example
functional programming disallows side-effects altogether. This allows
effortless chaining of functions, something you cannot do with your
function (subroutine really) that modifies things in place.  Maybe you
need to reexamine what your basic data structures are and need to be.
If you need a block of mutable values to do your processing on, perhaps
that should be encapsulated into its own set of routines.

Sounds like this is a case where you could alter your method to better
fit Python's strengths, rather than work around it's differences or
weaknesses compared to a language like C.

But it could be that Python is ill-suited to this kind of bit-twiddling
and that C is the proper place to do it (Chris has argued for this from
the beginning).





More information about the Python-list mailing list