python philosophical question - strong vs duck typing

[John Nagle]

On 1/9/2012 2:45 AM, Robert Kern wrote:
> On 1/9/12 5:35 AM, John Nagle wrote:
>
>> 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.
>
> You keep repeating this falsehood about the GIL. You have been
> repeatedly shown that this is false[1][2], though I have yet to see you
> acknowledge it. The GIL exists to protect Python's internal data
> structures, mostly the reference counts on objects. The reason that the
> attempts to remove the GIL from CPython have not been accepted is
> because they cause unacceptable performance losses in the common
> unthreaded case. In implementations of Python that do not use reference
> counting, there is no GIL. Neither Jython nor IronPython have a GIL, but
> they both have the standard Python semantics that let you store
> variables into modules from the outside, even from other threads.
>
> [1] http://mail.python.org/pipermail/python-list/2011-February/1265760.html
> [2] http://mail.python.org/pipermail/python-list/2011-April/1269056.html

     If you don't have a global lock, then you have to have lots
of implicit locks, probably one on every symbol dictionary.
IronPython does this well, though; their dictionaries do not
require locking for read access, only for writes.  So they
avoid running up the overhead on routine symbol access.

     Some operations which CPython users assume are atomic,
such as list append, are not atomic in IronPython.
(See "http://ironpython.codeplex.com/wikipage?title=FAQ")
The GIL does more than just protect memory allocation.
If you want to retain the semantics of CPython, the
implementation pretty much has to be slow.  The
"Unladen Swallow" project crashed and burned because of
that fact.  They couldn't even get 2x over CPython.

     There are still too many unnecessary dictionary lookups
when running Python.  Most of those could be optimized out
at compile time if, when compiling a module, the compiler
didn't have to worry about the module being altered from
outside itself.


				John Nagle