Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #18450 > unrolled thread

Re: python philosophical question - strong vs duck typing

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: python philosophical question - strong vs duck typing Terry Reedy <tjreedy@udel.edu> - 2012-01-03 15:38 -0500
    Re: python philosophical question - strong vs duck typing Ben Finney <ben+python@benfinney.id.au> - 2012-01-04 10:10 +1100
    Re: python philosophical question - strong vs duck typing alex23 <wuwei23@gmail.com> - 2012-01-03 18:15 -0800
      Re: python philosophical question - strong vs duck typing John Nagle <nagle@animats.com> - 2012-01-08 21:35 -0800
        Re: python philosophical question - strong vs duck typing Robert Kern <robert.kern@gmail.com> - 2012-01-09 10:45 +0000
          Re: python philosophical question - strong vs duck typing John Nagle <nagle@animats.com> - 2012-01-13 09:30 -0800
        Re: python philosophical question - strong vs duck typing Lie Ryan <lie.1296@gmail.com> - 2012-01-11 00:05 +1100

#18450 — Re: python philosophical question - strong vs duck typing

On 1/3/2012 1:13 PM, Sean Wolfe wrote:

> I have a theoretical / philosophical question regarding strong vs duck
> typing in Python. Let's say we wanted to type strongly in Python and

Python objects are strongly typed, in any sensible meaning of the term.
What you mean is statically or explicitly typing names.

> were willing to compromise our code to the extent necessary, eg not
> changing variable types or casting or whatever. Let's say there was a
> methodology in Python to declare variable types.
>
> The question is, given this possibility, would this get us closer to
> being able to compile down to a language like C or C++?

Cython compiles Python as is to C. It also gives the option to add type 
annotations to names to get faster code. Shredskin compiles a subset of 
Python, or a subset of usages, to C, with similar benefits.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#18464

Terry Reedy <tjreedy@udel.edu> writes:

> On 1/3/2012 1:13 PM, Sean Wolfe wrote:
>
> > I have a theoretical / philosophical question regarding strong vs
> > duck typing in Python. Let's say we wanted to type strongly in
> > Python
>
> Python objects are strongly typed, in any sensible meaning of the
> term. What you mean is statically or explicitly typing names.

For more on the various spectrums of type systems, and the terms to use,
see <URL:https://en.wikipedia.org/wiki/Type_system>.

-- 
 \      “If I haven't seen as far as others, it is because giants were |
  `\                           standing on my shoulders.” —Hal Abelson |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#18479

On Jan 4, 6:38 am, Terry Reedy <tjre...@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.

[toc] | [prev] | [next] | [standalone]

#18699

On 1/3/2012 6:15 PM, alex23 wrote:
> On Jan 4, 6:38 am, Terry Reedy<tjre...@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

[toc] | [prev] | [next] | [standalone]

#18705

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

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#18931

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

[toc] | [prev] | [next] | [standalone]

#18758

On 01/09/2012 04:35 PM, John Nagle wrote:
> 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.

With a smart enough compiler, JIT compiler can actually be faster than 
compile-time optimizations; the reason being that different people might 
use the same code differently. For example, say we have a function that 
takes an array of numbers which can be integer or float or a mix of 
integers and floats. A compile-time optimizer cannot optimize this 
function safely; but a run-time optimizer might notice that a certain 
user only ever use the function with an array of integers and generate 
an optimized code for that particular case.

Profile-guided optimizations (PGO) can do something similar, but then it 
means a single program will have to have twenty different binaries for 
twenty different use cases; or a very large binary that contains code 
optimized for every possible thing.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web