Python is slow

[David C. Ullrich]

On Fri, 23 May 2008 14:00:33 -0700 (PDT),
"bruno.desthuilliers at gmail.com" <bruno.desthuilliers at gmail.com> wrote:

>On 23 mai, 10:42, "inhahe" <inh... at gmail.com> wrote:
>> "Bruno Desthuilliers" <bruno.42.desthuilli... at websiteburo.invalid> wrote in
>> messagenews:4836772e$0$6097$426a74cc at news.free.fr...
>>
>> > Brad a écrit :
>> >> cm_gui wrote:
>> >>> Python is slow.
>>
>> >> It ain't C++, but it ain't a punch card either... somewhere in between. I
>> >> find it suitable for lots of stuff. I use C++ when performance really
>> >> matters tho... right tool for the job. Learn a good interpreted language
>> >> (Pyhton) and a good compiled language (C or C++)
>>
>> > LordHaveMercy(tm). Could you guys please learn what you're talking about?
>>
>> > 1/ being interpreted or compiled (for whatever definition of these
>> > terms) is not a property of a language, but a property of an
>> > implementation of a language.
>>
>> That's like saying being spherical is not a property of planets, it's a
>> property of an instanciation of a planet.
>
>I do definitively not have the required knowledge to say anything
>about "being spherical" being part of the definition of what a
>"planet" is or not.

I wasn't going to mention this since it's really not relevant,
but since you raise the question: Actually it was a bad analogy
because being roughly spherical _is_ part of the definition of
"planet". (Of course "spherical" must mean "roughly spherical"
here, since no planet is exactly spherical.)

A little while ago when Pluto got demoted so it's no longer
officially a planet they came up with a definition - part of
the definition is that the body is large enough that gravity
causes it to assume a spherical shape.

>>, and b) It's a far cry to
>> imagine a planet coming into being that's not spherical
>
>Idem
>
>>  (a language as
>> dynamic as Python, or most other scripting languages, would be either
>> extremely difficult or impossible to make a native compiler for).
>
>Now this I can tell is false. The problem is not that it's difficult
>to "make a native compiler for" dynamic languages, the problem is that
>it's difficult to write native compiler for dynamic languages that
>generates code that beats the VM/byte-code interpreter/whatever you
>name it to be wotrh the effort.
>
>> I guess I
>> should also mention that Python isn't very practical (as in "suitable",
>> "right tool for the job", and "perfomance", as mentioned in the above post)
>> without an implementation.
>
>That is debatable. There are algorithm courses taught in "pseudo-code"
>- that is, a language that doesn't have any known implementation.
>
>> So I don't think this distinction has any use
>> other than to beat other people over the head with a bat.
>
>Ok, *you* know this - I mean, the distinction between a language and a
>language's implementation(s).  Are you sure everyone saying - or
>reading - assertions such as "language XXX is slow" or "compiled
>languages are faster" etc really know what they're talking about ?
>
>> > 2/ actually, all known Python implementations compile to byte-code.
>>
>> Which is then interpreted, but you're still technically right, because
>> "compiled" can mean either compiled to bytecode or compiled to native code,
>> despite what it actually did mean.  Semantics FTW!!
>
>Yes, semantics. But a bit more than semantics - byte-code interpreters
>are usually way faster than "pure" interpreter, and start to be fast
>enough for quite a lot of practical use.
>
>Ok, I'll stop on this - once again, sorry for the noise, and please
>bear with me, I tend to be a bit too much on the pedantic side
>sometimes. But still, thanks to the pedantics peoples on usenet that
>taught me so much so far and still teach me more and more...

David C. Ullrich