python philosophical question - strong vs duck typing

[John Nagle]

On 1/3/2012 6:15 PM, alex23 wrote:
> On Jan 4, 6:38 am, Terry Reedy<tjre... at udel.edu>  wrote:
>> Shredskin compiles a subset of
>> Python, or a subset of usages, to C, with similar benefits.
>
> That is, of course, 'Shedskin' and 'C++' :)
>
> +1 for either Cython or Shedskin as your next step for more performant
> Python.

    I've tried Shed Skin, and it's an excellent idea that's not ready for
prime time.  One guy did it all, and it needs a greater level of effort
than that.  It does do well on numeric code.

    There's a reason for that.  If you can figure out at compile time
which variables can be represented as "int", "bool", "char" (or 
"wchar_t") and "double", performance on numeric work improves
enormously.  CPython boxes everything, including integers, in
a "CObject" object, so there's dispatching overhead just to add
two numbers.

    A type-inferring compiler has to analyze the whole program at
once, because the type of a function's arguments is determined
by its callers.  This is slow.  The alternative is to guess
what the type of something is likely to be, compile code at
run time, and be prepared to back out a bad guess.  This
requires a very complex system, but that's how PyPy does it.
Performance does not seem to reach Shed Skin levels.

    Python has some serious problems that preclude optimization.
Basically, the language is designed to be run by a naive 
(non-optimizing) interpreter, and allows things that are easy
for such an implementation but very tough to optimize.  An
example is the ability to store into the variables of a module
from outside it, and even from another thread.  Every attempt
to get rid of the Global Interpreter Lock has hit that problem.

				John Nagle