Re: Python is slow?

[José Matos]

On Monday 06 October 2008 00:01:50 Lawrence D'Oliveiro wrote:
> Not listed as one
> .

Look further
http://directory.fsf.org/project/gnuplot/

-- 
José Abílio
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Tue, Dec 23, 2008 at 4:42 AM, cm_gui  wrote:
> i am referring mainly to Python for web applications.
>
> Python is slow.

Please just go away. You are making
an embarrassment of yourself.

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 22, 3:42 pm, cm_gui  wrote:
> Python is slow.

Haven't you said that already?
Well, you did it so many times that you convinced me...

I'll tell the Google folks that they are a bunch of ignorant fools for
choosing python.
That's why their business is doing that bad. They will surely go to
hell.
This Google search engine and that silly site "youtube"... they won't
work.
THEY ARE SLOW!

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[cm_gui]

On Dec 22, 6:51 am, Lou Pecora  wrote:
> In article ,
>  "James Mills"  wrote:
>
> > In case anyone is not aware, Python is
> > also used for heavy scientific computational
> > problems, games such as Civilisation and
> > others, and I believe (correct me if I"m wrong)
> > it's also used by NASA.
>
> > --JamesMills
>

i am referring mainly to Python for web applications.

Python is slow.

> Python has become very popular in scientific computation.  You'll find
> it in use lots of places (universities, national labs, defense labs).  I
> use it for solving partial differential equations for quantum chaos
> calculations and went to C for speed up where needed using ctypes which
> is very straightforward and plays nice with numpy array/matrix
> libraries.  I've been doing scientific programming for 30 years.  Python
> with C extensions and libraries is the best approach I've ever used.  
> Calculation speed is not a problem and the code can be "tweaked" to
> increase it easily.  Programming speed is incredible.  I can get
> substantial object oriented code up and running much faster than
> anything I've ever used.
>
> --
> -- Lou Pecora

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Lou Pecora]

In article ,
 "James Mills"  wrote:

> In case anyone is not aware, Python is
> also used for heavy scientific computational
> problems, games such as Civilisation and
> others, and I believe (correct me if I"m wrong)
> it's also used by NASA.
> 
> --JamesMills

Python has become very popular in scientific computation.  You'll find 
it in use lots of places (universities, national labs, defense labs).  I 
use it for solving partial differential equations for quantum chaos 
calculations and went to C for speed up where needed using ctypes which 
is very straightforward and plays nice with numpy array/matrix 
libraries.  I've been doing scientific programming for 30 years.  Python 
with C extensions and libraries is the best approach I've ever used.  
Calculation speed is not a problem and the code can be "tweaked" to 
increase it easily.  Programming speed is incredible.  I can get 
substantial object oriented code up and running much faster than 
anything I've ever used.

-- 
-- Lou Pecora
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Mon, Dec 22, 2008 at 4:47 AM, r  wrote:
> Could not have said it better myself Luis, i stay as far away from C
> as i can. But there are usage cases for it.

If you can think of 1 typical common case
I'll reward you with praise! :)

By the way, by common and typical I mean
use-cases that you'd typically find in every
day applications and user tools, software,
games, etc.

In case anyone is not aware, Python is
also used for heavy scientific computational
problems, games such as Civilisation and
others, and I believe (correct me if I"m wrong)
it's also used by NASA.

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

Could not have said it better myself Luis, i stay as far away from C
as i can. But there are usage cases for it.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 21, 2:34 pm, r  wrote:
> RTFM, use as much python code and optimize with C where needed,
> problem solved!

That's true if your *really* need C's extra speed.
Most of the times, a better algorithm or psyco (or shedskin) can help
without having to use any other language.
This is unless you are hacking a kernel, writing device drivers or 3D
image processing.
For anything else, python is fast enough if you know how to optimize
your code.

Luis
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

RTFM, use as much python code and optimize with C where needed,
problem solved!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Krishnakant]

With my current experience with java, python and perl, I can only
suggest one thing to who ever feels that python or any language is slow.
By the way there is only one language with is fastest and that is
assembly.
And with regards to python, I am writing pritty heavy duty applications
right now.
Just to mention I am totally blind and I use a screen reader called orca
on the gnome desktop.  I hope readers here can understand that a screen
reader has to do a lot of real-time information processing and respond
with lightenning speed.
And Orca the scree reader is coded totally in python.
So that is one example.
So conclusion is is how you enhance your program by utilising the best
aspects of python.
happy hacking.
Krishnakant.
On Sun, 2008-12-21 at 16:33 +, MRAB wrote:
> Marc 'BlackJack' Rintsch wrote:
> > On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote:
> > 
> >>> Seriously cm_gui, you're a fool.
> >>> Python is not slow.
> >> haha, getting hostile?
> >> python fans sure are a nasty crowd.
> >>
> >> Python is SLOW.
> >>
> >> when i have the time, i will elaborate on this.
> > 
> > You are not fast enough to elaborate on Python's slowness!?  :-)
> > 
> > cm_gui is slow!
> > 
> > Ciao,
> > Marc 'BlackJack' Rintsch
> > 
> Correction:
> 
> cm_gui is SLOW! :-)
> --
> http://mail.python.org/mailman/listinfo/python-list

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[MRAB]

Marc 'BlackJack' Rintsch wrote:

On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote:


Seriously cm_gui, you're a fool.
Python is not slow.

haha, getting hostile?
python fans sure are a nasty crowd.

Python is SLOW.

when i have the time, i will elaborate on this.


You are not fast enough to elaborate on Python's slowness!?  :-)

cm_gui is slow!

Ciao,
Marc 'BlackJack' Rintsch


Correction:

cm_gui is SLOW! :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Marc 'BlackJack' Rintsch]

On Sat, 20 Dec 2008 14:18:40 -0800, cm_gui wrote:

>> Seriously cm_gui, you're a fool.
>> Python is not slow.
> 
> haha, getting hostile?
> python fans sure are a nasty crowd.
> 
> Python is SLOW.
> 
> when i have the time, i will elaborate on this.

You are not fast enough to elaborate on Python's slowness!?  :-)

cm_gui is slow!

Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Steve Holden]

cm_gui wrote:
>> Seriously cm_gui, you're a fool.
>> Python is not slow.
>>
>> --JamesMills
> 
> haha, getting hostile?
> python fans sure are a nasty crowd.
> 
> Python is SLOW.
> 
Two lies in one posting!

> when i have the time, i will elaborate on this.
> 
Save your time, go somewhere else. Nobody here is interested.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[cm_gui]

> Seriously cm_gui, you're a fool.
> Python is not slow.
>
> --JamesMills

haha, getting hostile?
python fans sure are a nasty crowd.

Python is SLOW.

when i have the time, i will elaborate on this.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[RadicalEd]

On Dec 10, 1:42 pm, cm_gui  wrote:
> http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> I fully agree with Krzysztof Kowalczyk .
> Can't they build a faster VM for Python since they love the language
> so much?
>
> Python is SLOW.    And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!
>
> Just go to any Python website and you will know.
> An example is:http://www2.ljworld.com/
> And this site is created by the creators of Django!
>
> And it is not just this Python site that is slow. There are many many
> Python sites which are very slow. And please don’t say that it could
> be the web hosting or the server which is slow — because when so many
> Python sites are slower than PHP sites, it couldn’t be the web
> hosting.   Also, Zope/Plone is even slower.
>
> Python is slow. Very slow.

I did a DataBase consult with MySQLdb and PHP with 30 rows and who
you think was the better and faster, YES, Python for almost 10
seconds, and I have to configure the php.ini for PHP could show me the
DATA.
He is just a futile troll frustrated with Python.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

On Dec 16, 5:47 pm, "James Mills" 
wrote:
> On Wed, Dec 17, 2008 at 9:08 AM, r  wrote:
> > What about all the crap you had to go through just to get output?
> > Python wins
>
> Yes I can't say I really enjoy writing C (at all!)
> _except_ in the case where I may need to
> optimise some heavy computation. But then
> again with multi-core CPUs these days and
> cheap hardware, distributed processing is
> not only easy, but very effective! And I still
> wouldn't resort to C because well umm
> psyco is just awesome!
>
> --JamesMills

This idiot(cm_gui) just needs to RTFM before going off on tirades like
a 3 year old. What i find so funny is after Luis asked "what's the
blazingly fast application you need to write so desperately?" we have
yet to hear from this "expert programmer". He is probably still trying
to get "hello world" to compile.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Wed, Dec 17, 2008 at 9:08 AM, r  wrote:
> What about all the crap you had to go through just to get output?
> Python wins

Yes I can't say I really enjoy writing C (at all!)
_except_ in the case where I may need to
optimise some heavy computation. But then
again with multi-core CPUs these days and
cheap hardware, distributed processing is
not only easy, but very effective! And I still
wouldn't resort to C because well umm
psyco is just awesome!

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

What about all the crap you had to go through just to get output?
Python wins

PS. cm_gui try this piece of code
>>> print 'hello world'.replace('world', 'idiot')
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Stef Mientki]

r wrote:

On Dec 15, 7:15 am, Luis M. González  wrote:
  

On Dec 15, 1:38 am, cm_gui  wrote:



hahaha, do you know how much money they are spending on hardware to
make
youtube.com fast???
  

By the way... I know of a very slow Python site called YouTube.com. In
fact, it is so slow that nobody ever uses it.


Buddy, just stop whining and go with c++ if it makes you happy.
By the way, what's the blazingly fast application you need to write so
desperately?
What kind of performance problem have you find in python that makes
you so unhappy?
What are you going to do with all the extra speed provided by c++ (a
Hello World! ?)...



Still no reply from cm_gui, he must have googled "C hello world" :D
  

or cm_gui is slow,
btw I thought r was a statistic package ;-)
cheers,
Stef

--
http://mail.python.org/mailman/listinfo/python-list
  


--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

n Wed, Dec 17, 2008 at 8:24 AM, r  wrote:
>> What kind of performance problem have you find in python that makes
>> you so unhappy?
>> What are you going to do with all the extra speed provided by c++ (a
>> Hello World! ?)...
>
> Still no reply from cm_gui, he must have googled "C hello world" :D

I must be mad for doing this - but I feel so strongly
about this topic. In 99.9% of cases generally things
are "feast enough"! So here goes:

jmi...@atomant:~$ cat - > hello.c
int main (int argc, char ** argv) {
printf("Hello World!\n!");
}
jmi...@atomant:~$ tcc hello.c -o hello
jmi...@atomant:~$ wc -l hello.c
3 hello.c
jmi...@atomant:~$ ls -l hello.c
-rw-r--r-- 1 jmills jmills 69 2008-12-17 08:41 hello.c
jmi...@atomant:~$ ls -l hello
-rwxr-xr-x 1 jmills jmills 2972 2008-12-17 08:41 hello

jmi...@atomant:~$ time ./hello
Hello World!
!
real0m0.003s
user0m0.000s
sys 0m0.004s

jmi...@atomant:~$ cat - > hello.py
print "Hello World!"

jmi...@atomant:~$ time python hello.py
Hello World!

real0m0.129s
user0m0.016s
sys 0m0.020s

OMG OMG OMG! Python is slower!
If you compare "sys" times ~5x slower!

BUT ... This is in fact a misleading as most of
this is in the startup time. So let's be fairer:

jmi...@atomant:~$ time python -E -S hello.py
Hello World!

real0m0.011s
user0m0.008s
sys 0m0.004s

Wow! Only ~2x as slow as C.

--JamesMills

PS: Yet another useless post!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[r]

On Dec 15, 7:15 am, Luis M. González  wrote:
> On Dec 15, 1:38 am, cm_gui  wrote:
>
> > hahaha, do you know how much money they are spending on hardware to
> > make
> > youtube.com fast???
>
> > > By the way... I know of a very slow Python site called YouTube.com. In
> > > fact, it is so slow that nobody ever uses it.
>
> Buddy, just stop whining and go with c++ if it makes you happy.
> By the way, what's the blazingly fast application you need to write so
> desperately?
> What kind of performance problem have you find in python that makes
> you so unhappy?
> What are you going to do with all the extra speed provided by c++ (a
> Hello World! ?)...

Still no reply from cm_gui, he must have googled "C hello world" :D
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Craig Allen]

On Dec 14, 6:38 pm, cm_gui  wrote:
> hahaha, do you know how much money they are spending on hardware to
> make
> youtube.com fast???
>
> > By the way... I know of a very slow Python site called YouTube.com. In
> > fact, it is so slow that nobody ever uses it.

less than they'd spend to implement it in C
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Tomasz Rola]

On Fri, 12 Dec 2008, bearophileh...@lycos.com wrote:

> In the next years people that use low-level languages like C may need
> to invent a new language fitter for multi-core CPUs, able to be used
> on GPUs too (see the OpenCL), less error-prone than C, able to use the
> CPU vector instructions efficiently. (The D language is probably unfit
> for this purpose, because even if it's meant to be a system language,
> I don't think it can be used much to replace C everywhere it's used
> now.) A C+ maybe? :-)
> 
> Bye,
> bearophile

I would say, this probably will be some descendant of Erlang and/or 
Haskell. As evolutionary step, they look very promising to me, they just 
are "not quite there" yet. As of C++, I cannot tell before I read their 
new standard.

Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[George Sakkis]

On Dec 15, 8:15 am, Luis M. González  wrote:
> On Dec 15, 1:38 am, cm_gui  wrote:
>
> > hahaha, do you know how much money they are spending on hardware to
> > make
> > youtube.com fast???
>
> > > By the way... I know of a very slow Python site called YouTube.com. In
> > > fact, it is so slow that nobody ever uses it.
>
> Buddy, just stop whining and go with c++ if it makes you happy.
> By the way, what's the blazingly fast application you need to write so
> desperately?
> What kind of performance problem have you find in python that makes
> you so unhappy?
> What are you going to do with all the extra speed provided by c++ (a
> Hello World! ?)...

Folks, do you *really* feel the urge to feed this troll and his 8-year-
old "arguments" again and again ? Please think twice before hitting
send on this pointless thread.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 15, 1:38 am, cm_gui  wrote:
> hahaha, do you know how much money they are spending on hardware to
> make
> youtube.com fast???
>
> > By the way... I know of a very slow Python site called YouTube.com. In
> > fact, it is so slow that nobody ever uses it.
>
>

Buddy, just stop whining and go with c++ if it makes you happy.
By the way, what's the blazingly fast application you need to write so
desperately?
What kind of performance problem have you find in python that makes
you so unhappy?
What are you going to do with all the extra speed provided by c++ (a
Hello World! ?)...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Mon, Dec 15, 2008 at 5:26 PM, Andreas Kostyrka  wrote:
> So to summarize, Python is fast enough for even demanding stuff, and
> when done correctly even number crunching or binary parsing huge files
> or possible in competitive speeds. But you sometime need a developer
> that can wield the tool with a certain experience, and not a stupid
> rookie that whines that his tool does not make his O(n**n) algorithm
> automatically blazing fast.

Amen! +10

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Steven D'Aprano]

On Sun, 14 Dec 2008 20:38:58 -0800, cm_gui wrote:

>> By the way... I know of a very slow Python site called YouTube.com. In
>> fact, it is so slow that nobody ever uses it.
>
> hahaha, do you know how much money they are spending on hardware to make
> youtube.com fast???

Oooh, I know!

ONE MILLION DOLLARS

And still cheaper and easier than re-writing YouTube's infrastructure in 
another language.



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Andreas Kostyrka]

Am Sun, 14 Dec 2008 20:38:58 -0800 (PST)
schrieb cm_gui :

> 
> hahaha, do you know how much money they are spending on hardware to
> make
> youtube.com fast???

yeah, as they do for basically all big sites, no matter what language
is used for implementation.

Next is the fact that it's rather simple with Python to meet speed
demands where external factors like Gb vs 10Gb network cards are the
limiting factor.

And last, you do realize that most "simple" websites do hinge on the
performance and scalability of the underlying SQL server. In practice
some languages like PHP do force that "LAMP" model much stronger on the
developer, which makes developing systems that scale beyond a certain
point a challenge.

So to summarize, Python is fast enough for even demanding stuff, and
when done correctly even number crunching or binary parsing huge files
or possible in competitive speeds. But you sometime need a developer
that can wield the tool with a certain experience, and not a stupid
rookie that whines that his tool does not make his O(n**n) algorithm
automatically blazing fast.

Andreas


> 
> > By the way... I know of a very slow Python site called YouTube.com.
> > In fact, it is so slow that nobody ever uses it.
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Mon, Dec 15, 2008 at 2:59 PM, James Mills
 wrote:
> On Mon, Dec 15, 2008 at 2:44 PM, Benjamin Kaplan
>  wrote:
>> On Sun, Dec 14, 2008 at 11:38 PM, cm_gui  wrote:
>>>
>>> hahaha, do you know how much money they are spending on hardware to
>>> make
>>> youtube.com fast???
>>
>> Obviously not enough to get to the point where it's cheaper to have the
>> programmers write C code. And the hardware is more for handling the intense
>> traffic that YouTube gets, not for speeding up the site.
>
> Seriously cm_gui, you're a fool.
> Python is not slow.

And I should clarify that by stating
that the CPython interpreter is NOT slow.

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

On Mon, Dec 15, 2008 at 2:44 PM, Benjamin Kaplan
 wrote:
> On Sun, Dec 14, 2008 at 11:38 PM, cm_gui  wrote:
>>
>> hahaha, do you know how much money they are spending on hardware to
>> make
>> youtube.com fast???
>
> Obviously not enough to get to the point where it's cheaper to have the
> programmers write C code. And the hardware is more for handling the intense
> traffic that YouTube gets, not for speeding up the site.

Seriously cm_gui, you're a fool.
Python is not slow.

--JamesMills
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Benjamin Kaplan]

On Sun, Dec 14, 2008 at 11:38 PM, cm_gui  wrote:

>
> hahaha, do you know how much money they are spending on hardware to
> make
> youtube.com fast???


Obviously not enough to get to the point where it's cheaper to have the
programmers write C code. And the hardware is more for handling the intense
traffic that YouTube gets, not for speeding up the site.


>
>
> > By the way... I know of a very slow Python site called YouTube.com. In
> > fact, it is so slow that nobody ever uses it.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[cm_gui]

hahaha, do you know how much money they are spending on hardware to
make
youtube.com fast???

> By the way... I know of a very slow Python site called YouTube.com. In
> fact, it is so slow that nobody ever uses it.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Benjamin Kaplan]

On Sat, Dec 13, 2008 at 3:35 PM, sturlamolden  wrote:

> On 10 Des, 19:42, cm_gui  wrote:
>
> > And it is not just this Python site that is slow. There are many many
> > Python sites which are very slow. And please don't say that it could
> > be the web hosting or the server which is slow — because when so many
> > Python sites are slower than PHP sites, it couldn't be the web
> > hosting.   Also, Zope/Plone is even slower.
> >
> > Python is slow. Very slow.
>
>
> By the way... I know of a very slow Python site called YouTube.com. In
> fact, it is so slow that nobody ever uses it.
>


And there's also a web crawler written in Python, used by a site called
Google, that's so slow that the search engine gives very few results.


>
>
>
>
>
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[sturlamolden]

On 10 Des, 19:42, cm_gui  wrote:

> And it is not just this Python site that is slow. There are many many
> Python sites which are very slow. And please don’t say that it could
> be the web hosting or the server which is slow — because when so many
> Python sites are slower than PHP sites, it couldn’t be the web
> hosting.   Also, Zope/Plone is even slower.
>
> Python is slow. Very slow.


By the way... I know of a very slow Python site called YouTube.com. In
fact, it is so slow that nobody ever uses it.









--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Isaac Gouy]

On Dec 12, 11:41 am, Bruno Desthuilliers
 wrote:
> sturlamolden a écrit :
> (snip)
>
> > Creating a fast implementation of a dynamic language is almost rocket
> > science. But it has been done. There is Stronghold, the fastest
> > version of Smalltalk known to man, on which the Sun Java VM is based.
> > On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3
>
> cf bearophile's comment on this point (CPU architecture and RAM)
>
> > And
> > most of that magic comes from an implementation of a dynamically typed
> > language (Smalltalk).
>
> Err... Where is _Java_ "dynamic" actually ? A benchmark of _Smalltalk_
> VM vs CPython VM would make more sense.


http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=python


>
> > Second, there are other fast implementations of dynamic languages. The
> > CMUCL and SBCL versions of Common Lisp comes to min; you can see how
> > SBCL does in the same benchmark (CMUCL tends to be even faster).
>
> Could it be that there are some type hints in the lisp versions of the
> source code ?
>
> > So Python is a lot slower than it needs to be.
>
> Please fix it, you're welcome.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Isaac Gouy]

On Dec 12, 6:58 am, bearophileh...@lycos.com wrote:
> sturlamolden:
>
> > On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3 And
> > most of that magic comes from an implementation of a dynamically typed
> > language (Smalltalk). [...]
> >http://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=all
>
> That is indeed a nice result, JavaVM has come a long way from the
> first one used for applets. That result comes mostly from the fact
> that this is a test on a 4-core CPU, that is less easy to manage from
> C. You can see that in the single 64-bit core 
> tests:http://shootout.alioth.debian.org/u64/benchmark.php?test=all〈=all


Whether or not it's less easy to manage from C is unclear, but you are
correct to point out few of those C programs have been updated to
exploit quadcore - so the reasonable comparison is with C++.


And the benchmarks game also provides x86 measurements with programs
forced onto a single core which shows GCC ahead

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all



> And take a look at the memory used too, up to 34 times higher for the
> JVM on the 4-core CPU.
>
> In the next years people that use low-level languages like C may need
> to invent a new language fitter for multi-core CPUs, able to be used
> on GPUs too (see the OpenCL), less error-prone than C, able to use the
> CPU vector instructions efficiently. (The D language is probably unfit
> for this purpose, because even if it's meant to be a system language,
> I don't think it can be used much to replace C everywhere it's used
> now.) A C+ maybe? :-)
>
> I agree that CPython may quite enjoy having something built-in like
> Psyco, but it's a lot of work for an open source project. Probably
> with 1/3 or 1/2 of the work poured on PyPy you may create that
> improvement for CPython. Maybe PyPy will someday produce some fruit,
> but I think they have used the wrong strategy: instead of trying to
> create something very new that someday will work, it's often better to
> try to improve something that today everybody uses, AND try to be
> useful from almost the very beginning.
>
> Bye,
> bearophile

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Bruno Desthuilliers]

sturlamolden a écrit :
(snip)


Creating a fast implementation of a dynamic language is almost rocket
science. But it has been done. There is Stronghold, the fastest
version of Smalltalk known to man, on which the Sun Java VM is based.
On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3


cf bearophile's comment on this point (CPU architecture and RAM)


And
most of that magic comes from an implementation of a dynamically typed
language (Smalltalk).


Err... Where is _Java_ "dynamic" actually ? A benchmark of _Smalltalk_ 
VM vs CPython VM would make more sense.



Second, there are other fast implementations of dynamic languages. The
CMUCL and SBCL versions of Common Lisp comes to min; you can see how
SBCL does in the same benchmark (CMUCL tends to be even faster).


Could it be that there are some type hints in the lisp versions of the 
source code ?


So Python is a lot slower than it needs to be. 


Please fix it, you're welcome.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Andreas Kostyrka]

On Fri, Dec 12, 2008 at 06:17:43AM -0800, sturlamolden wrote:
> None of those projects addresses inefficacies in the CPython
> interpreter, except for psyco - which died of an overdose PyPy.

Bullshit. All that discussion about performance forgets that performance is a 
function of the whole system, not the language.

Worse you can measure it really badly.

E.g. it's relative simple to compare CPython versus IronPython versus Jython. 
For a given benchmark program.

As programs do not trivially translate from language A to language B, nor does 
fluency in language A make you automatically fluent in
language B after learning the syntax.



> 
> PyPy is interesting if they ever will be able to produce something
> useful. They have yet to prove that. Even if PyPy can come up with a
> Python JIT, they will still be decades behind the technologies of
> Strongtalk and Java. That is the problem with reinventing the wheel
> all over again.

Well, it's reinventing the wheel. The problem that Java is a different kind of 
wheel 
(boxed vs. unboxed objects, plus more static compile time bindings), Smalltalk 
is also different (e.g. multiple inheritence),
so you need to have a specific toolbox for the wheel, sorry. Keeping and 
enhancing the tribal wisdom
about toolbox design is what a subtribe of the Computer Scientists do.

Btw, Psyco is not a JIT like most JVMs had them, it's a specializing compiler. 
JVM JITs traditionally speeded up the unboxed data 
type operations. Psyco does something comparable, but it has to specialize 
first on data types. The end effect is similiar, but the 
background of what happens is quite different.

> 
> Not to forget LLVM and Parrot which also will support Python
> frontends.
When they do, they'll do. There have flown quite a bit of Python version since 
the time that it was announced that
Parrot will have a Python frontend.

Andreas
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 12, 11:17 am, sturlamolden  wrote:
> On Dec 12, 3:04 pm, Luis M. González  wrote:
>
> > Why don't you guys google a little bit to know what's being done to
> > address python's "slowness"??
>
> Nothing is being done, and woth Py3k it got even worse.
>
> > It has been mentioned in this thread the pypy project (isn't it enough
> > for you??)
> > Other hints: shedskin, psyco, pyrex...
>
> None of those projects addresses inefficacies in the CPython
> interpreter, except for psyco - which died of an overdose PyPy.
>
> PyPy is interesting if they ever will be able to produce something
> useful. They have yet to prove that. Even if PyPy can come up with a
> Python JIT, they will still be decades behind the technologies of
> Strongtalk and Java. That is the problem with reinventing the wheel
> all over again.
>
> Not to forget LLVM and Parrot which also will support Python
> frontends.

So, what's your conclusion?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Christian Heimes]

sturlamolden schrieb:
> On Dec 12, 3:04 pm, Luis M. González  wrote:
> 
>> Why don't you guys google a little bit to know what's being done to
>> address python's "slowness"??
> 
> Nothing is being done, and woth Py3k it got even worse.

Indeed, it *is* slower for now. As I already said in another thread our
top priorities were feature completeness and bug fixing. Optimizations
will follow the features in the near future.

Christian

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Stefan Behnel]

sturlamolden wrote:
> How is the numpy support in Cython going? It was supposed to know
> about ndarrays natively.

It does.


> I.e. not treat them as Python objects, but
> rather as known C structs. That way an operation like arr[n] would not
> result in a callback to Python, but translate directly to fast pointer
> arithmetics.

http://docs.cython.org/docs/numpy_tutorial.html

Stefan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[MRAB]

sturlamolden wrote:

On Dec 12, 3:04 pm, Luis M. González  wrote:


Why don't you guys google a little bit to know what's being done to
address python's "slowness"??


Nothing is being done, and woth Py3k it got even worse.


It has been mentioned in this thread the pypy project (isn't it enough
for you??)
Other hints: shedskin, psyco, pyrex...


None of those projects addresses inefficacies in the CPython
interpreter, except for psyco - which died of an overdose PyPy.

PyPy is interesting if they ever will be able to produce something
useful. They have yet to prove that. Even if PyPy can come up with a
Python JIT, they will still be decades behind the technologies of
Strongtalk and Java. That is the problem with reinventing the wheel
all over again.

Not to forget LLVM and Parrot which also will support Python
frontends.

Python is developed and maintained by volunteers. If you'd like to have 
a go at writing a JIT interpreter for it, then go ahead. No-one here 
will stop you.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[bearophileHUGS]

sturlamolden:
> On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3 And
> most of that magic comes from an implementation of a dynamically typed
> language (Smalltalk). [...]
> http://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=all

That is indeed a nice result, JavaVM has come a long way from the
first one used for applets. That result comes mostly from the fact
that this is a test on a 4-core CPU, that is less easy to manage from
C. You can see that in the single 64-bit core tests:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=all
And take a look at the memory used too, up to 34 times higher for the
JVM on the 4-core CPU.

In the next years people that use low-level languages like C may need
to invent a new language fitter for multi-core CPUs, able to be used
on GPUs too (see the OpenCL), less error-prone than C, able to use the
CPU vector instructions efficiently. (The D language is probably unfit
for this purpose, because even if it's meant to be a system language,
I don't think it can be used much to replace C everywhere it's used
now.) A C+ maybe? :-)

I agree that CPython may quite enjoy having something built-in like
Psyco, but it's a lot of work for an open source project. Probably
with 1/3 or 1/2 of the work poured on PyPy you may create that
improvement for CPython. Maybe PyPy will someday produce some fruit,
but I think they have used the wrong strategy: instead of trying to
create something very new that someday will work, it's often better to
try to improve something that today everybody uses, AND try to be
useful from almost the very beginning.

Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[sturlamolden]

On Dec 12, 3:43 pm, Stefan Behnel  wrote:

> http://cython.org/

How is the numpy support in Cython going? It was supposed to know
about ndarrays natively. I.e. not treat them as Python objects, but
rather as known C structs. That way an operation like arr[n] would not
result in a callback to Python, but translate directly to fast pointer
arithmetics.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Stefan Behnel]

David Cournapeau wrote:
> I want faster function
> calls to use with numpy: do you know of any solution ?

http://cython.org/

Stefan
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[sturlamolden]

On Dec 12, 3:27 pm, "David Cournapeau"  wrote:

> I want faster function
> calls to use with numpy: do you know of any solution ? Pypy certainly
> isn't, at least today.

An interesting thing for numpy would be to use CUDA. If we can move
floating point ops to the GPU, a common desktop computer could yield
teraflops. A subclass of ndarray could be written for the nvidia GPU.

Using OpenMP within NumPy would also be interesting. There are desktop
computers available today with two quadcore processors.

There is multiprocessing, which works nicely with numpy. You can even
have multiple processes working on ndarrys that point to the same
shared memory. Just allocate a multiprocessing.Array and use its
buffer to create ndarray views.




--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[David Cournapeau]

On Fri, Dec 12, 2008 at 11:04 PM, Luis M. González  wrote:

> It has been mentioned in this thread the pypy project (isn't it enough
> for you??)

Since pypy can't be used today for most production use (most python
packages can't work on it), I don't see how it could be enough for
anyone interested in solving problems today. I want faster function
calls to use with numpy: do you know of any solution ? Pypy certainly
isn't, at least today.

cheers,

David
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[sturlamolden]

On Dec 12, 3:04 pm, Luis M. González  wrote:

> Why don't you guys google a little bit to know what's being done to
> address python's "slowness"??

Nothing is being done, and woth Py3k it got even worse.


> It has been mentioned in this thread the pypy project (isn't it enough
> for you??)
> Other hints: shedskin, psyco, pyrex...

None of those projects addresses inefficacies in the CPython
interpreter, except for psyco - which died of an overdose PyPy.

PyPy is interesting if they ever will be able to produce something
useful. They have yet to prove that. Even if PyPy can come up with a
Python JIT, they will still be decades behind the technologies of
Strongtalk and Java. That is the problem with reinventing the wheel
all over again.

Not to forget LLVM and Parrot which also will support Python
frontends.












--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 12, 10:43 am, sturlamolden  wrote:
> On Dec 12, 2:29 pm, sturlamolden  wrote:
>
> > Creating a fast implementation of a dynamic language is almost rocket
> > science. But it has been done. There is Stronghold,
>
> I meant of course Strongtalk...

Blah, blah, blah...
Why don't you guys google a little bit to know what's being done to
address python's "slowness"??
It has been mentioned in this thread the pypy project (isn't it enough
for you??)
Other hints: shedskin, psyco, pyrex...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[sturlamolden]

On Dec 12, 2:29 pm, sturlamolden  wrote:

> Creating a fast implementation of a dynamic language is almost rocket
> science. But it has been done. There is Stronghold,

I meant of course Strongtalk...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[sturlamolden]

On Dec 11, 4:25 am, Carl Banks  wrote:

> cm_gui is TROLL.  And I am not compring it with bots like Aaron
> Castironpi Brody.  cm_gui is even troller than Xah Lee!

Sure he is a troll, but he also have a point. Python is slower than it
needs to be.

Creating a fast implementation of a dynamic language is almost rocket
science. But it has been done. There is Stronghold, the fastest
version of Smalltalk known to man, on which the Sun Java VM is based.
On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3 And
most of that magic comes from an implementation of a dynamically typed
language (Smalltalk). A Python interpreter based on Strontalk would be
interesting...

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all

Second, there are other fast implementations of dynamic languages. The
CMUCL and SBCL versions of Common Lisp comes to min; you can see how
SBCL does in the same benchmark (CMUCL tends to be even faster).

So Python is a lot slower than it needs to be. But in most cases,
perceived 'slowness' comes from bad programming.

http://www.strongtalk.org/






--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Marco Mariani]

Giampaolo Rodola' wrote:


The real (and still unsolved) problem with PyPy is the installation
which requires something like a dozen of third-party packages to be
installed.
Unfortunately it seems there are no plans yet for releasing any
Windows/Linux/Mac installer in the near future.


I'm not using it, but at least Ubuntu 8.10 has the .deb packages of pypy 
1.0. And I remember installing a release last year in a few minutes, 
during a conference talk.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Giampaolo Rodola']

On 11 Dic, 13:06, Luis M. González  wrote:
> On Dec 10, 3:42 pm, cm_gui  wrote:
>
>
>
>
>
> >http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> > I fully agree with Krzysztof Kowalczyk .
> > Can't they build a faster VM for Python since they love the language
> > so much?
>
> > Python is SLOW.And I am not comparing it with compiled languages
> > like C.
> > Python is even slower than PHP!
>
> > Just go to any Python website and you will know.
> > An example is:http://www2.ljworld.com/
> > And this site is created by the creators of Django!
>
> > And it is not just this Python site that is slow. There are many many
> > Python sites which are very slow. And please don’t say that it could
> > be the web hosting or the server which is slow — because when so many
> > Python sites are slower than PHP sites, it couldn’t be the web
> > hosting.   Also, Zope/Plone is even slower.
>
> > Python is slow. Very slow.
>
> Now seriously, just to finish your idiotic rant, check the Pypy
> project:
>
> http://codespeak.net/pypyhttp://morepypy.blogspot.com
>
> And if you still think this is not enough, why don't you help these
> guys to make it faster?
>
> Luis- Nascondi testo citato
>
> - Mostra testo citato -

The real (and still unsolved) problem with PyPy is the installation
which requires something like a dozen of third-party packages to be
installed.
Unfortunately it seems there are no plans yet for releasing any
Windows/Linux/Mac installer in the near future.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[jay....@gmail.com]

On Dec 11, 7:06 am, Luis M. González <[EMAIL PROTECTED]> wrote:
> On Dec 10, 3:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
>
>
>
> >http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> > I fully agree with Krzysztof Kowalczyk .
> > Can't they build a faster VM for Python since they love the language
> > so much?
>
> > Python is SLOW.And I am not comparing it with compiled languages
> > like C.
> > Python is even slower than PHP!
>
> > Just go to any Python website and you will know.
> > An example is:http://www2.ljworld.com/
> > And this site is created by the creators of Django!
>
> > And it is not just this Python site that is slow. There are many many
> > Python sites which are very slow. And please don’t say that it could
> > be the web hosting or the server which is slow — because when so many
> > Python sites are slower than PHP sites, it couldn’t be the web
> > hosting.   Also, Zope/Plone is even slower.
>
> > Python is slow. Very slow.
>
> Now seriously, just to finish your idiotic rant, check the Pypy
> project:
>
> http://codespeak.net/pypyhttp://morepypy.blogspot.com
>
> And if you still think this is not enough, why don't you help these
> guys to make it faster?
>
> Luis

PyPy looks pretty sweet.  I'm glad this discussion was started.  There
always seems to be this buzz about python being slow.  So what if it's
not as fast as C?  I make that up by cutting down development time.  I
figured if I ever ran into something being too slow, that I'd just
have to learn c extensions and replace the bottle necks.  In 2007 I
wrote a system in python that communicated to an autopilot on an
autonomously flying aircraft at real-time.  We never had any speed
issues.  I have not played with django much and I do not typically
develop web apps, but the slowness really must be bloated algorithms
in the libraries you are using.  Programming in other languages (java,
c, c++, c# etc) is not an issue for me, but next to python it's like
writing with a feather and ink instead of a ball point pen.  I have to
put more time into working with the tools I'm using than actually
getting the job done.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

On Dec 10, 3:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> I fully agree with Krzysztof Kowalczyk .
> Can't they build a faster VM for Python since they love the language
> so much?
>
> Python is SLOW.    And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!
>
> Just go to any Python website and you will know.
> An example is:http://www2.ljworld.com/
> And this site is created by the creators of Django!
>
> And it is not just this Python site that is slow. There are many many
> Python sites which are very slow. And please don’t say that it could
> be the web hosting or the server which is slow — because when so many
> Python sites are slower than PHP sites, it couldn’t be the web
> hosting.   Also, Zope/Plone is even slower.
>
> Python is slow. Very slow.


Now seriously, just to finish your idiotic rant, check the Pypy
project:

http://codespeak.net/pypy
http://morepypy.blogspot.com

And if you still think this is not enough, why don't you help these
guys to make it faster?

Luis
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Jeremiah Dodds]

Does anybody else think it's really funny when people argue over which
language used for _web apps_ is fastest? I mean, I'm not aware of any
language that's slow enough to make it noticeable compared to say, network
latency or database access. I guess you might notice if you're not caching
any content, and your language of choice is _really_ bad at generating
strings in a for loop.

As far as "slow" goes, the clear winner(?) is Ruby, and there are _plenty_
of sites written in ruby that aren't slow. The ones that are slow aren't
slow because of ruby  - they're slow primarily because of people not knowing
how to write a database schema, as far as I can tell.

There seems to be a lot of stigma against python as being a "slow" language,
which I suppose it is when measured in certain ways - however it's more than
fast enough for me, and is certainly fast enough for web-apps (I run a few
sites on top of CherryPy, and have _never_ had an issue with them, even with
a minor redditing on one of them).

I had a freelance gig once porting an image-manipulation algorithm from C++
to python. It was a horrible mess of C++ code, but ran very fast (and did
exactly what my employer needed it to do). Porting it to python in a literal
led to (IIRC) a 10x speed-down. Changing that to more idiomatic python made
it only 3-5x slower than the C++. After translating that into, I think,
PyRex, it was barely slower than the original code. Certainly well within
the "acceptable" range.

When I did the above, I was really pretty new to python. If I did the same
job again, I'd probably get better results, just from understanding the
language better. But I digress.

The only places that I'm aware of where performance would be enough of an
issue to make Python a poor choice are places where using python would
_never_ be considered anyhow.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[MRAB]

Benjamin Kaplan wrote:



On Wed, Dec 10, 2008 at 10:25 PM, Carl Banks <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


On Dec 10, 12:42 pm, cm_gui <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
 > Python is SLOW.And I am not comparing it with compiled languages
 > like C.
 > Python is even slower than PHP!


cm_gui is TROLL.  And I am not compring it with bots like Aaron
Castironpi Brody.  cm_gui is even troller than Xah Lee!


actually Castironpi has made some coherent replies lately. Xah Lee is 
worse than ever though.



Perhaps there's a Law of Conservation of Trolling. :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Benjamin Kaplan]

On Wed, Dec 10, 2008 at 10:25 PM, Carl Banks <[EMAIL PROTECTED]>wrote:

> On Dec 10, 12:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> > Python is SLOW.And I am not comparing it with compiled languages
> > like C.
> > Python is even slower than PHP!
>
>
> cm_gui is TROLL.  And I am not compring it with bots like Aaron
> Castironpi Brody.  cm_gui is even troller than Xah Lee!
>

actually Castironpi has made some coherent replies lately. Xah Lee is worse
than ever though.

>
>
> Carl Banks
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Carl Banks]

On Dec 10, 12:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> Python is SLOW.    And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!


cm_gui is TROLL.  And I am not compring it with bots like Aaron
Castironpi Brody.  cm_gui is even troller than Xah Lee!


Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[James Mills]

@em_gui: You are outrightly wrong.

Why ? Python's VM is not slow! In fact it's quite fast.
What does tend to be slow is sloppy poorly designed
code. Django/Turbogears (sorry for any devs reading this)
are large frameworks with a lot of complexity - and yes
they tend to be a little cumbersome and slow.

CherryPy (1) on the other hand is quite fast, but it is not
your kitchen-sink type framework as Django and Turbogears
tends to be.

Before you start making such ridiculous stupid claims
about the performance of Python's VM and Python itself
actually do some work, do some tests, show us some of
your work ?

And RYI, I'm the author of a (fairly) general purpose
event driven library (framework) with a focus on Component
architectures. This is called circuits (2). As well as being
an event-driven library which performs really really well,
it also has "Web Components" (circuits.lib.web) that make
CherryPy look too hard to use and ~4x slower. Yes circuits
on decent hardware performs (raw speeds) of ~3000 req/s.
I have used circuits to build commercial web applications
for clients in conjunction with ExtJS (3) and loading time
for the entire app is usually ~1-2s. Data response times
are usually in the order of 50-100ms.

SLow ? I don't think so.

--JamesMils

References:
 1. http://www.cherrypy.org/
 2. http://trac.softcircuit.com.au/circuits/
 3. http://www.extjs.com/

On Thu, Dec 11, 2008 at 9:39 AM, cm_gui <[EMAIL PROTECTED]> wrote:
> You guys are living in denial.
> Python is SLOW, especially for web apps.
>
> Instead of getting mad, why don't get together and come up with a
> faster VM/interpreter?
>
> The emperor doesn't like to be told he is not wearing any clothes?
>
>
> On 10 Dec, 14:48, Luis M. González <[EMAIL PROTECTED]> wrote:
>> You are WRONG, WRONG, WRONG!!
>> And when I say Wrong, I mean WRONG!!!
>>
>> And I am not saying that you are confussed.
>> I say that you are WRONG!
>>
>> And when someone says so many times that you are wrong, it is because
>> you are WRONG!
>> And don't say that you are not wrong, because you are wrong!
>>
>> You are Wrong. Very Wrong.
>>
>> On Dec 10, 3:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
>>
>> >http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>>
>> > I fully agree with Krzysztof Kowalczyk .
>> > Can't they build a faster VM for Python since they love the language
>> > so much?
>>
>> > Python is SLOW.And I am not comparing it with compiled languages
>> > like C.
>> > Python is even slower than PHP!
>
>
>>
>> > Just go to any Python website and you will know.
>> > An example is:http://www2.ljworld.com/
>> > And this site is created by the creators of Django!
>>
>> > And it is not just this Python site that is slow. There are many many
>> > Python sites which are very slow. And please don't say that it could
>> > be the web hosting or the server which is slow — because when so many
>> > Python sites are slower than PHP sites, it couldn't be the web
>> > hosting.   Also, Zope/Plone is even slower.
>>
>> > Python is slow. Very slow.
>>
>>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
--
-- "Problems are solved by method"
--
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Python is slow

[acerimusdux]

cm_gui wrote:

You guys are living in denial.
Python is SLOW, especially for web apps.

Instead of getting mad, why don't get together and come up with a
faster VM/interpreter?

The emperor doesn't like to be told he is not wearing any clothes?


O


The one in denial is the one without any evidence to back his 
assertions. as someone once said, "In God we Trust. All others must have 
data."


For example, the most recent benchmarks from The Computer Language 
Benchmark Game:


http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=al
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

On Gentoo on a Pentium 4 for example:

mean
07.10 Python Psyco
19.34 Lua
23.00 Python
28.27 Perl
30.00 PHP
66.28 Javascript SpiderMonkey
75.12 Ruby

I have no idea about Zope, but if that's slow, go complain to the 
devlopers of Zope. The Python interpreter is one of the fastest for a 
dynamically interpreted language. And Psyco is competitive with many 
other JIT compilers. I would think someone who has been obsessing about 
the speed of Python since May, and especially interested in a Python 
"VM" would have learned by now about Psyco?









--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[cm_gui]

You guys are living in denial.
Python is SLOW, especially for web apps.

Instead of getting mad, why don't get together and come up with a
faster VM/interpreter?

The emperor doesn't like to be told he is not wearing any clothes?


On 10 Dec, 14:48, Luis M. González <[EMAIL PROTECTED]> wrote:
> You are WRONG, WRONG, WRONG!!
> And when I say Wrong, I mean WRONG!!!
>
> And I am not saying that you are confussed.
> I say that you are WRONG!
>
> And when someone says so many times that you are wrong, it is because
> you are WRONG!
> And don't say that you are not wrong, because you are wrong!
>
> You are Wrong. Very Wrong.
>
> On Dec 10, 3:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
>
> >http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> > I fully agree with Krzysztof Kowalczyk .
> > Can't they build a faster VM for Python since they love the language
> > so much?
>
> > Python is SLOW.    And I am not comparing it with compiled languages
> > like C.
> > Python is even slower than PHP!


>
> > Just go to any Python website and you will know.
> > An example is:http://www2.ljworld.com/
> > And this site is created by the creators of Django!
>
> > And it is not just this Python site that is slow. There are many many
> > Python sites which are very slow. And please don’t say that it could
> > be the web hosting or the server which is slow — because when so many
> > Python sites are slower than PHP sites, it couldn’t be the web
> > hosting.   Also, Zope/Plone is even slower.
>
> > Python is slow. Very slow.
>
>

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Luis M . González]

You are WRONG, WRONG, WRONG!!
And when I say Wrong, I mean WRONG!!!

And I am not saying that you are confussed.
I say that you are WRONG!

And when someone says so many times that you are wrong, it is because
you are WRONG!
And don't say that you are not wrong, because you are wrong!

You are Wrong. Very Wrong.


On Dec 10, 3:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> I fully agree with Krzysztof Kowalczyk .
> Can't they build a faster VM for Python since they love the language
> so much?
>
> Python is SLOW.    And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!
>
> Just go to any Python website and you will know.
> An example is:http://www2.ljworld.com/
> And this site is created by the creators of Django!
>
> And it is not just this Python site that is slow. There are many many
> Python sites which are very slow. And please don’t say that it could
> be the web hosting or the server which is slow — because when so many
> Python sites are slower than PHP sites, it couldn’t be the web
> hosting.   Also, Zope/Plone is even slower.
>
> Python is slow. Very slow.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Arnaud Delobelle]

cm_gui <[EMAIL PROTECTED]> writes:

[stuff]
> Python is slow. Very slow.

The same troll started this same flame earlier this year:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/5cea684680f63c82?q=

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Bruno Desthuilliers]

cm_gui a écrit :

(snip FUD)

see also: 
http://groups.google.com/group/comp.lang.python/browse_frm/thread/5cea684680f63c82


by the same troll^M^M^M^M^Msmart guy.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[D'Arcy J.M. Cain]

On Wed, 10 Dec 2008 21:04:12 +0100
Stef Mientki <[EMAIL PROTECTED]> wrote:
> cm_gui wrote:
> > [...]  
> Put this guy in the junk filter,

What's the point if people like you are just going to repost his entire
message like that?

-- 
D'Arcy J.M. Cain <[EMAIL PROTECTED]> |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Stef Mientki]

cm_gui wrote:

http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-a-faster-python-vm.html

I fully agree with Krzysztof Kowalczyk .
Can't they build a faster VM for Python since they love the language
so much?

Python is SLOW.And I am not comparing it with compiled languages
like C.
Python is even slower than PHP!

Just go to any Python website and you will know.
An example is:
http://www2.ljworld.com/
And this site is created by the creators of Django!

And it is not just this Python site that is slow. There are many many
Python sites which are very slow. And please don’t say that it could
be the web hosting or the server which is slow — because when so many
Python sites are slower than PHP sites, it couldn’t be the web
hosting.   Also, Zope/Plone is even slower.

Python is slow. Very slow.

--
http://mail.python.org/mailman/listinfo/python-list
  

Put this guy in the junk filter,
in may of this year he (or it) started the same discussion.
Stef
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[George Sakkis]

On Dec 10, 1:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:

> http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> I fully agree with Krzysztof Kowalczyk .
> Can't they build a faster VM for Python since they love the language
> so much?

WTF is Krzysztof Kowalczyk and why should we care ?

Thanks for playing, the exit for the trolls is right down the hall.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Duncan Booth]

Tim Chase <[EMAIL PROTECTED]> wrote:

> [nibbling a little flame-bait]
> 
>> Python is even slower than PHP!
>> 
>> Just go to any Python website and you will know.
>> An example is:
>> http://www2.ljworld.com/
> 
> I'm not sure I'm seeing what you're seeing -- the dynamic page 
> loaded in under 2 seconds -- about on par with sun.com, 
> python.org, php.net or msn.com all being pulled from non-cached 
> servers.  You sure you're not mistaking your bandwidth and/or 
> browser-rendering slowness for Python-as-a-web-server slowness?
> 
For another example try http://www.novell.com. That's a Plone site which 
gets a lot of visitors and isn't noticeably slow.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Jason Scheirer]

On Dec 10, 10:42 am, cm_gui <[EMAIL PROTECTED]> wrote:
> http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-...
>
> I fully agree with Krzysztof Kowalczyk .
> Can't they build a faster VM for Python since they love the language
> so much?
>
> Python is SLOW.    And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!
>
> Just go to any Python website and you will know.
> An example is:http://www2.ljworld.com/
> And this site is created by the creators of Django!
>
> And it is not just this Python site that is slow. There are many many
> Python sites which are very slow. And please don’t say that it could
> be the web hosting or the server which is slow — because when so many
> Python sites are slower than PHP sites, it couldn’t be the web
> hosting.   Also, Zope/Plone is even slower.
>
> Python is slow. Very slow.

I have two responses, and could not decide which one to post. Then I
figured I could just do both.

--

Response 1:

You have stumbled on to our plot! We use Python because we hate
getting things done and love nothing more than waiting for things to
complete, because that means more time to drink coffee. Python is a
hoax pushed on the world by the Vast Conspiracy Of People Who Actually
Never Get Anything Done But Enjoy Watching Things Scroll By Very
Slowly While Drinking Coffee.

--

Response 2:

Are you new to Python and frustrated with it? Is that where this is
coming from? If so, I am sorry that Python is so hard.

You can use Jython and get the Java VM or IronPython and get the CLR
VM. There's an immediate fix there for your objections to the CPython
VM. You could investigate getting some higher performance code going
using Stackless. Or move to event-based coding in Twisted and avoid
lots of while loop spins and locking/threading mischief and the other
things that come with network-bound programming like web development.
The PyPy project is also writing a fast Python intepreter with
multiple code output options. Or you can also profile your existing
code and optimize. Or integrate NumPy and Psyco into your efforts. And
you have the advantage of writing C extensions where it makes sense if
you're using CPython -- it's relatively easy and has resulted in fewer
than a dozen fatalities over the course of its existence. There are
options galore here, and 'Python' is actually a large, diverse
ecosystem. Web development is one thing Python does, but is not its
specialized purpose. PHP is a collection of tragic mistakes that
masquerades as a scripting language for the web.

I'd like to see some data on the response times of sites running
various Python web frameworks against each other and versus sites in
other languages. I'm also curious about the perception of speed versus
actual speed here -- if a site pushes 125k of page data a second at a
constant rate or pushes it all in 125k chunks in one second intervals,
the first is going to 'feel' faster initially even though both will
finish transferring the data at the same time and have identical page
load times. And if you're dealing with massive amounts of static
content (javascript frameworks, css, etc) that only needs to go over
the wire one then yeah, the page is going to be slow ON FIRST LOAD but
from then on have 90% of what it needs in local cache, so subsequent
page loads will be smaller and faster. That appears to be the case
with ljworld, at least.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Thorsten Kampe]

* cm_gui (Wed, 10 Dec 2008 10:42:40 -0800 (PST))> 
> Python is SLOW.And I am not comparing it with compiled languages
> like C.
> Python is even slower than PHP!

Sure. But Perl is faster than Ruby (exactly 2.53 times as fast). And 
Python is 1.525 times faster than VisualBasic (or was it the other way 
round?).
 
> Just go to any Python website and you will know.
> An example is:
> http://www2.ljworld.com/
> And this site is created by the creators of Django!

Quite slow, indeed! Django is even slower than Python itself...
 
> And it is not just this Python site that is slow. There are many many
> Python sites which are very slow. And please don’t say that it could
> be the web hosting or the server which is slow — because when so many
> Python sites are slower than PHP sites, it couldn’t be the web
> hosting.   Also, Zope/Plone is even slower.

I hope this will awaken the community. I did a quick test and it seems 
that Zope is slower than Python but Python is faster than Plone and PHP 
is faster than even Perl and Python _together_...!

Thanks for the heads-up, cm_gui!

Thorsten
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Tim Chase]

[nibbling a little flame-bait]


Python is even slower than PHP!

Just go to any Python website and you will know.
An example is:
http://www2.ljworld.com/


I'm not sure I'm seeing what you're seeing -- the dynamic page 
loaded in under 2 seconds -- about on par with sun.com, 
python.org, php.net or msn.com all being pulled from non-cached 
servers.  You sure you're not mistaking your bandwidth and/or 
browser-rendering slowness for Python-as-a-web-server slowness?



Would it be nice if Python was faster?  Sure, why not?

Does it meet my needs speed-wise?  99% of the time, yes.  With 
Psyco, 99.9% of the time.  As has been shown repeatedly over the 
last couple months, algorithm-choice makes a far greater impact 
than some python tweaks.  Most of my time spent waiting is 
usually on I/O (disk, network, or user).  And those times I've 
experienced slowness where I'm not waiting on I/O, it's always 
been an algorithm aspect (an O(N**2) fuzzy comparison algorithm 
is my prime offender).  A faster Python might shave a 30-60 
seconds off a 10 minute run, but it's still a walk around the 
office either way.



Python is slow. Very slow.


However until you have a use-case that *you* have implemented 
with *real code*, publicly vetted the algorithm, and THEN find it 
slow as demonstrated by profiled timings, I'm afraid it's all 
just unsubstantiated hot air to say categorically that "python is 
slow".  It might be "too slow to do some particular CPU-intensive 
task", but it's repeatedly proven quite sufficient for a wide 
variety of development needs.


-tkc




--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Benjamin Kaplan]

On Wed, Dec 10, 2008 at 2:07 PM, Paul McGuire <[EMAIL PROTECTED]> wrote:

> On Dec 10, 12:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> > Python is slow. Very slow.
>
> And... ?   Was there a question or specific suggestion in there
> somewhere?
>
> Do you go to your mechanic and say "My car wont go as fast as the
> other cars on the road!  They should make it faster!"?
>
> Good luck to you in your futile, uh I meant, *future* endeavors.  (No
> wait, I really meant "futile".)
>
> -- Paul
>

Don't bother arguing. It's just a pathetic attempt to start a flame war.

>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow

[Paul McGuire]

On Dec 10, 12:42 pm, cm_gui <[EMAIL PROTECTED]> wrote:
> Python is slow. Very slow.

And... ?   Was there a question or specific suggestion in there
somewhere?

Do you go to your mechanic and say "My car wont go as fast as the
other cars on the road!  They should make it faster!"?

Good luck to you in your futile, uh I meant, *future* endeavors.  (No
wait, I really meant "futile".)

-- Paul
--
http://mail.python.org/mailman/listinfo/python-list

Python is slow

[cm_gui]

http://blog.kowalczyk.info/blog/2008/07/05/why-google-should-sponsor-a-faster-python-vm.html

I fully agree with Krzysztof Kowalczyk .
Can't they build a faster VM for Python since they love the language
so much?

Python is SLOW.And I am not comparing it with compiled languages
like C.
Python is even slower than PHP!

Just go to any Python website and you will know.
An example is:
http://www2.ljworld.com/
And this site is created by the creators of Django!

And it is not just this Python site that is slow. There are many many
Python sites which are very slow. And please don’t say that it could
be the web hosting or the server which is slow — because when so many
Python sites are slower than PHP sites, it couldn’t be the web
hosting.   Also, Zope/Plone is even slower.

Python is slow. Very slow.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Lawrence D'Oliveiro]

In message <[EMAIL PROTECTED]>, Ben Finney wrote:

> Note that I consider a work free even if it fails to grant “the right
> to distribute misrepresentations of the author's words”, because that
> act is an exercise of undue power over another person, and so falls
> outside the limit imposed by the freedoms of others.

That's the difference between software and, say, an artistic work like a
novel, poem or illustration. Software is nearly always a work in progress.
That's why we have Free Software licences for the former, and Creative
Commons licences for the latter.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Lawrence D'Oliveiro]

In message <[EMAIL PROTECTED]>, José Matos
wrote:

> The gnuplot license is a free software according to FSF ...

Not listed as one
.

--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Lawrence D'Oliveiro]

In message <[EMAIL PROTECTED]>, Terry
Reedy wrote:

> greg wrote:
>
>> Steven D'Aprano wrote:
>> 
>>> We agree that the restriction is artificial, and I think irrational
>> 
>> I think it's irrational for another reason, too -- it's
>> actually vacuous. There's nothing to prevent you creating
>> a set of patches that simply say "Delete all of the original
>> source and replace it with the following".
>> 
>> Then you're effectively distributing the modified source in
>> its entirety, just with a funny header at the top of each
>> source file that serves no useful purpose.
> 
> The useful purpose is to show that you are distributing your work under
> someone else's product name, instead of making up your own as you ought
> to.

Except that the approach Terry Reedy gets around that without violating the
licence.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Terry Reedy]

greg wrote:

Steven D'Aprano wrote:


We agree that the restriction is artificial, and I think irrational


I think it's irrational for another reason, too -- it's
actually vacuous. There's nothing to prevent you creating
a set of patches that simply say "Delete all of the original
source and replace it with the following".

Then you're effectively distributing the modified source in
its entirety, just with a funny header at the top of each
source file that serves no useful purpose.


The useful purpose is to show that you are distributing your work under 
someone else's product name, instead of making up your own as you ought to.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[greg]

Steven D'Aprano wrote:


We agree that the restriction is artificial, and I think irrational


I think it's irrational for another reason, too -- it's
actually vacuous. There's nothing to prevent you creating
a set of patches that simply say "Delete all of the original
source and replace it with the following".

Then you're effectively distributing the modified source in
its entirety, just with a funny header at the top of each
source file that serves no useful purpose.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to search multiple textfiles ? (Python is slow ?)

[Lawrence D'Oliveiro]

In message <[EMAIL PROTECTED]>, Stef
Mientki wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <[EMAIL PROTECTED]>, Stef
>> Mientki wrote:
>>
>>> I'm really amazed by the speed of Python !!
>>> It can only be beaten by findstr, which is only available on windows.
>>
>> Did you try find -exec grep -F?
>>   
> well my windows version doesn't understand that :

I assumed when you said "It can only be beaten by findstr, which is only
available on windows", that meant you had tried some non-Windows options,
before concluding that Windows "findstr" was the fastest.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Ben Finney]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Wed, 01 Oct 2008 09:06:08 +1000, Ben Finney wrote:
> 
> > Note that I consider a work free even if it fails to grant “the
> > right to distribute misrepresentations of the author's words”,
> > because that act is an exercise of undue power over another
> > person, and so falls outside the limit imposed by the freedoms of
> > others.
> 
> But distributing modified source code *does* misrepresent the
> author's words, because you confuse authorship.

That's a possibility. There are other ways to avoid it than to
restrict the freedom to redistribute; for example, some licenses state
that modified works must clearly state who, when, and what was
modified. I would not consider that a non-free restriction, since the
freedom of the original distributor *and* the freedom of the
redistributor is preserved.

> If that is why the gnuplot people do not allow you to distribute
> such modified documents, then the only "freedom" they fail to grant
> is exactly the one you don't consider necessary for a free licence:
> "the right to distribute misrepresentations of the author's words".

We're going around in circles. I've already pointed out another
freedom they fail to grant: the freedom to redistribute a modified
work *as modified*. It's not equivalent to the act of
misrepresentation.

-- 
 \ “War is God's way of teaching geography to Americans.” —Ambrose |
  `\Bierce |
_o__)  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Steven D'Aprano]

On Wed, 01 Oct 2008 09:06:08 +1000, Ben Finney wrote:

> Terry Reedy <[EMAIL PROTECTED]> writes:
> 
>> Steven D'Aprano wrote:
>> > We agree that the restriction is artificial, and I think irrational
>> > (although I'd be interested in hearing the gnuplot developers'
>> > reasoning before making a final judgment).
>> 
>> I believe it is a matter of preserving clarity of authorship, just as
>> is the quoting mechanism we take for granted in posts like this. If I
>> removed the quote marks above and silently edited what Ben and you
>> wrote, I might upset someone and certainly could confuse readers.
> 
> That, if it were to be prosecuted under law, would be a matter already
> covered by laws other than copyright: fraud, libel, etc.
> 
> Note that I consider a work free even if it fails to grant “the right to
> distribute misrepresentations of the author's words”, because that act
> is an exercise of undue power over another person, and so falls outside
> the limit imposed by the freedoms of others.


But distributing modified source code *does* misrepresent the author's 
words, because you confuse authorship. Given only the modified version of 
the source code, how is the recipient supposed to identify which parts of 
the source code were written by the original authors and which parts 
where written by you?

If that is why the gnuplot people do not allow you to distribute such 
modified documents, then the only "freedom" they fail to grant is exactly 
the one you don't consider necessary for a free licence: "the right to 
distribute misrepresentations of the author's words".


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Ben Finney]

Terry Reedy <[EMAIL PROTECTED]> writes:

> Steven D'Aprano wrote:
> > We agree that the restriction is artificial, and I think
> > irrational (although I'd be interested in hearing the gnuplot
> > developers' reasoning before making a final judgment).
> 
> I believe it is a matter of preserving clarity of authorship, just
> as is the quoting mechanism we take for granted in posts like this.
> If I removed the quote marks above and silently edited what Ben and
> you wrote, I might upset someone and certainly could confuse
> readers.

That, if it were to be prosecuted under law, would be a matter already
covered by laws other than copyright: fraud, libel, etc.

Note that I consider a work free even if it fails to grant “the right
to distribute misrepresentations of the author's words”, because that
act is an exercise of undue power over another person, and so falls
outside the limit imposed by the freedoms of others.

-- 
 \ “What is it that makes a complete stranger dive into an icy |
  `\   river to save a solid gold baby? Maybe we'll never know.” —Jack |
_o__)   Handey |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Ben Finney]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> I simply don't think that having to run some variation on
> 
> patch -i patchfile.patch
> 
> is a requirement so onerous that it makes the gnuplot licence
> non-free. Perhaps I'm just more tolerant of eccentricities than you
> :)

The distinction here is that this command must be run by *every*
recipient of a modified work. A work where one must do that is more
onerous for *each* recipient than one where it's already been patched
for the recipient.

Thus there is value, and no loss of freedom, in you as a redistributor
doing that work *once* and then redistributing the work intact to any
recipient. Your freedom to do this useful, harmless action is
restricted artificially by copyright, and is not granted by the
license.

So, recipients of the 'gnuplot' code are artificially restricted from
performing an action useful to society that does no harm.

-- 
 \“The Bermuda Triangle got tired of warm weather. It moved to |
  `\   Alaska. Now Santa Claus is missing.” —Steven Wright |
_o__)  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Terry Reedy]

Steven D'Aprano wrote:

On Tue, 30 Sep 2008 22:19:57 +1000, Ben Finney wrote:



I do, because a natural, beneficial act (modify the work and
redistribute it) that has no technical reason to restrict, is
artifically restricted.


We agree that the restriction is artificial, and I think irrational 
(although I'd be interested in hearing the gnuplot developers' reasoning 
before making a final judgment). 


I believe it is a matter of preserving clarity of authorship, just as is 
the quoting mechanism we take for granted in posts like this.  If I 
removed the quote marks above and silently edited what Ben and you 
wrote, I might upset someone and certainly could confuse readers.


tjr


--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[José Matos]

On Tuesday 30 September 2008 16:04:35 George Sakkis wrote:
> What you're missing is that for Free Software (TM) zealots it's a
> matter of philosophical principle, totally unrelated to how easy is to
> overcome the restriction. There is not a "practicality beats purity"
> clause in the FSF Bible.

The gnuplot license is a free software according to FSF, what is the problem 
here after all?

> George

-- 
José Abílio
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[George Sakkis]

On Sep 30, 9:43 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:

> On Tue, 30 Sep 2008 22:19:57 +1000, Ben Finney wrote:
> > Steven D'Aprano <[EMAIL PROTECTED]> writes:
>
> >> On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
> >> > You're not free to modify gnuplot and redistribute the result.
>
> >> > That you're free to distribute patches is nice, but it's not enough
> >> > to make the work free. The freedom to help people by giving them an
> >> > *already-modified* gnuplot is restricted by the copyright holder.
>
> >> > It's an artificial restriction on redistribution of derived works,
> >> > making them second-class for the prupose of getting them into
> >> > people's hands.
>
> >> Yes it is. It seems a strange, unnecessary restriction. But is it
> >> sufficient to make it non-free? I don't think so.
>
> > I do, because a natural, beneficial act (modify the work and
> > redistribute it) that has no technical reason to restrict, is
> > artifically restricted.
>
> We agree that the restriction is artificial, and I think irrational
> (although I'd be interested in hearing the gnuplot developers' reasoning
> before making a final judgment).
>
> But I just don't see the requirement that modified software be
> distributed in form X (original source + diffs) versus form Y (modified
> source in a tar ball) or form Z (an rpm) to be that big a deal. Not
> enough to make it "non-free software".
>
> I simply don't think that having to run some variation on
>
> patch -i patchfile.patch
>
> is a requirement so onerous that it makes the gnuplot licence non-free.
> Perhaps I'm just more tolerant of eccentricities than you :)

What you're missing is that for Free Software (TM) zealots it's a
matter of philosophical principle, totally unrelated to how easy is to
overcome the restriction. There is not a "practicality beats purity"
clause in the FSF Bible.

George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Steven D'Aprano]

On Tue, 30 Sep 2008 22:19:57 +1000, Ben Finney wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
> 
>> On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
>> > You're not free to modify gnuplot and redistribute the result.
>> > 
>> > That you're free to distribute patches is nice, but it's not enough
>> > to make the work free. The freedom to help people by giving them an
>> > *already-modified* gnuplot is restricted by the copyright holder.
>> > 
>> > It's an artificial restriction on redistribution of derived works,
>> > making them second-class for the prupose of getting them into
>> > people's hands.
>> 
>> Yes it is. It seems a strange, unnecessary restriction. But is it
>> sufficient to make it non-free? I don't think so.
> 
> I do, because a natural, beneficial act (modify the work and
> redistribute it) that has no technical reason to restrict, is
> artifically restricted.

We agree that the restriction is artificial, and I think irrational 
(although I'd be interested in hearing the gnuplot developers' reasoning 
before making a final judgment). 

But I just don't see the requirement that modified software be 
distributed in form X (original source + diffs) versus form Y (modified 
source in a tar ball) or form Z (an rpm) to be that big a deal. Not 
enough to make it "non-free software".

I simply don't think that having to run some variation on

patch -i patchfile.patch

is a requirement so onerous that it makes the gnuplot licence non-free. 
Perhaps I'm just more tolerant of eccentricities than you :)


-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Paul Boddie]

On 30 Sep, 14:19, Ben Finney <[EMAIL PROTECTED]>
wrote:
>
> This is where the useful "your freedom to swing your fist ends at the
> tip of the other man's nose" applies: As soon as the act you wish to
> perform is restricting the freedom of another, you're not
> contemplating an act of freedom, but an act of power over another.
> Freedoms should be protected, but only within the limits imposed by
> the freedoms of others.

This is a very good explanation of what copyleft is all about. I
suppose one could regard copyleft as a means to preserve the "maximal
common freedom" in a system - if anyone else were to acquire more
power or privilege to do something, that would diminish the freedoms
of others.

Paul
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Ben Finney]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
> > You're not free to modify gnuplot and redistribute the result.
> > 
> > That you're free to distribute patches is nice, but it's not
> > enough to make the work free. The freedom to help people by giving
> > them an *already-modified* gnuplot is restricted by the copyright
> > holder.
> > 
> > It's an artificial restriction on redistribution of derived works,
> > making them second-class for the prupose of getting them into
> > people's hands.
> 
> Yes it is. It seems a strange, unnecessary restriction. But is it 
> sufficient to make it non-free? I don't think so.

I do, because a natural, beneficial act (modify the work and
redistribute it) that has no technical reason to restrict, is
artifically restricted.

> In case you are thinking that gnuplot allows people to *only*
> distribute the diffs, not the original source to apply the diffs
> onto, that is not the case. I quote from gnuplot > help copyright
> 
> "Permission to distribute the released version of the source code
> along with corresponding source modifications in the form of a patch
> file is granted with same provisions 2 through 4 for binary
> distributions."

That's what I refer to when I say that it artifically makes derived
works into second-class for the purpose of doing the beneficial act of
distributing them: the redistributor is artificially restricted from
making the work as useful as the original they received.

They have only the options to redistribute a work that is more
cumbersome for the recipient of that work, or not to redistribute at
all. That's not free redistribution.

> > I try to judge freedom of a software work by the freedoms granted
> > to all recipients of the work, not by the approval of some
> > organisation.
> 
> Yes, but you accept some restrictions as legitimate. For example, you 
> accept the restriction that the GPL makes that says you may not 
> redistribute a modified work without making the source code available.

Yes, which is why I was careful to say "the freedoms granted to all
recipients of the work".

The power to restrict a recipient of one's work (by choosing not to
grant them the freedoms you yourself had when you received the work)
reduces the freedoms available to all recipients of the work, even
though one party's power may be increased.

This is where the useful "your freedom to swing your fist ends at the
tip of the other man's nose" applies: As soon as the act you wish to
perform is restricting the freedom of another, you're not
contemplating an act of freedom, but an act of power over another.
Freedoms should be protected, but only within the limits imposed by
the freedoms of others.

> That's a restriction, but it's not enough to disqualify it from
> being a free software licence.

Specifically because it upholds the freedom of the recipient of a
derived work from having power exerted over them.

> In fact, that restriction is *necessary* to make it a free software
> licence in the sense we're talking about.

Not really; it's necessary to make it a copyleft license, which is a
way of preserving freedom as the work gets passed along.

Works can still be free software without being copyleft-licensed,
though. A license allowing free redistribution and requiring only
attribution be preserved is less restrictive than a copyleft; yet,
because it allows any free act (even as it also allows acts of power
over others), the work is free software.

> So "free" does not mean "no restrictions", it merely means "none of
> some sorts of restrictions, but other restrictions are okay".
> Likewise the restriction that GPL software must be distributed with
> a copy of the appropriate licence.

That's right, and I've explained above what restrictions I consider
justified, and why, and how to tell the difference.

-- 
 \  “Reichel's Law: A body on vacation tends to remain on vacation |
  `\unless acted upon by an outside force.” —Carol Reichel |
_o__)  |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Steven D'Aprano]

On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:

> Steven D'Aprano <[EMAIL PROTECTED]> writes:
> 
>> On Tue, 30 Sep 2008 14:50:26 +1300, Lawrence D'Oliveiro wrote:
>> 
>> > In message <[EMAIL PROTECTED]>, r0g wrote:
>> > 
>> >> You can only distribute modifications to gnuplot itself as patches,
>> >> but you can distribute it freely ...
> […]
> 
>> Where's the non-free bit?
> 
> You're not free to modify gnuplot and redistribute the result.
> 
> That you're free to distribute patches is nice, but it's not enough to
> make the work free. The freedom to help people by giving them an
> *already-modified* gnuplot is restricted by the copyright holder.
> 
> It's an artificial restriction on redistribution of derived works,
> making them second-class for the prupose of getting them into people's
> hands.

Yes it is. It seems a strange, unnecessary restriction. But is it 
sufficient to make it non-free? I don't think so.

In case you are thinking that gnuplot allows people to *only* distribute 
the diffs, not the original source to apply the diffs onto, that is not 
the case. I quote from gnuplot > help copyright

"Permission to distribute the released version of the source code along
with corresponding source modifications in the form of a patch file is
granted with same provisions 2 through 4 for binary distributions."

Those provisions aren't terribly onerous, although #3 may be considered a 
privacy issue:

2. add special version identification to distinguish your version
in addition to the base release version number,
3. provide your name and address as the primary contact for the
support of your modified version, and
4. retain our contact information in regard to use of the base
software.




>> Personally, I don't get the whole "only distribute patches"
>> requirement. It's a bit like saying "You're free to distribute this
>> software, but only as a tarball". It seems silly to me.
> 
> That, too, would be a non-free requirement.
> 
>> But I don't see it as non-free, except in the sense that "only licences
>> approved by the FSF are free".
> 
> I try to judge freedom of a software work by the freedoms granted to all
> recipients of the work, not by the approval of some organisation.

Yes, but you accept some restrictions as legitimate. For example, you 
accept the restriction that the GPL makes that says you may not 
redistribute a modified work without making the source code available. 
That's a restriction, but it's not enough to disqualify it from being a 
free software licence. In fact, that restriction is *necessary* to make 
it a free software licence in the sense we're talking about. So "free" 
does not mean "no restrictions", it merely means "none of some sorts of 
restrictions, but other restrictions are okay". Likewise the restriction 
that GPL software must be distributed with a copy of the appropriate 
licence.

It is useful to compare the "diffs only" licence to two different GPL-
related scenarios. Scenario one is clearly against the spirit of the GPL, 
and possibly (hopefully!) the letter as well. Scenario two is not.

(1) I distribute the modified source code encrypted and charge $1,000,000 
for a NON-TRANSFERABLE licence to the encryption key. If you don't have 
the encryption key, that's your bad luck.

(2) I distribute the modified source code archived in a tar file, and 
refuse to offer it in any other format. If you don't have an untar 
application, that's your bad luck.

It's my contention that the restriction of supplying diffs is closer to 
Scenario 2 than to Scenario 1. The modified source is supplied, but it is 
split into two pieces: the official source, plus a set of diffs. 
Reversing that to get the modified source is not much more difficult than 
untarring a tarball.




-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Ben Finney]

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Tue, 30 Sep 2008 14:50:26 +1300, Lawrence D'Oliveiro wrote:
> 
> > In message <[EMAIL PROTECTED]>, r0g wrote:
> > 
> >> You can only distribute modifications to gnuplot itself as
> >> patches, but you can distribute it freely ...
[…]

> Where's the non-free bit?

You're not free to modify gnuplot and redistribute the result.

That you're free to distribute patches is nice, but it's not enough to
make the work free. The freedom to help people by giving them an
*already-modified* gnuplot is restricted by the copyright holder.

It's an artificial restriction on redistribution of derived works,
making them second-class for the prupose of getting them into people's
hands.

> Personally, I don't get the whole "only distribute patches"
> requirement. It's a bit like saying "You're free to distribute this
> software, but only as a tarball". It seems silly to me.

That, too, would be a non-free requirement.

> But I don't see it as non-free, except in the sense that "only
> licences approved by the FSF are free".

I try to judge freedom of a software work by the freedoms granted to
all recipients of the work, not by the approval of some organisation.

-- 
 \ “When I turned two I was really anxious, because I'd doubled my |
  `\   age in a year. I thought, if this keeps up, by the time I'm six |
_o__)  I'll be ninety.” —Steven Wright |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Steven D'Aprano]

On Tue, 30 Sep 2008 14:50:26 +1300, Lawrence D'Oliveiro wrote:

> In message <[EMAIL PROTECTED]>, r0g wrote:
> 
>> You can only distribute modifications to gnuplot itself as patches, but
>> you can distribute it freely ...
> 
> This must be some new definition of "freely" of which I'm unaware.

You're free to distribute the official release of gnuplot.

You're free to distribute patches to gnuplot.

You're even free to provide people with a script or program to apply 
those patches to gnuplot.


Where's the non-free bit?


Personally, I don't get the whole "only distribute patches" requirement. 
It's a bit like saying "You're free to distribute this software, but only 
as a tarball". It seems silly to me. But I don't see it as non-free, 
except in the sense that "only licences approved by the FSF are free".



-- 
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Lawrence D'Oliveiro]

In message <[EMAIL PROTECTED]>, r0g wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <[EMAIL PROTECTED]>, r0g wrote:
>> 
>>> You can only distribute modifications to gnuplot itself as
>>> patches, but you can distribute it freely ...
>> 
>> This must be some new definition of "freely" of which I'm unaware.
> 
> As in beer.

You get free beer?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[r0g]

Lawrence D'Oliveiro wrote:
> In message <[EMAIL PROTECTED]>, r0g wrote:
> 
>> You can only distribute modifications to gnuplot itself as
>> patches, but you can distribute it freely ...
> 
> This must be some new definition of "freely" of which I'm unaware.

As in beer.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Lawrence D'Oliveiro]

In message <[EMAIL PROTECTED]>, r0g wrote:

> You can only distribute modifications to gnuplot itself as
> patches, but you can distribute it freely ...

This must be some new definition of "freely" of which I'm unaware.
--
http://mail.python.org/mailman/listinfo/python-list

Re: how to search multiple textfiles ? (Python is slow ?)

[Stef Mientki]

Lawrence D'Oliveiro wrote:

In message <[EMAIL PROTECTED]>, Stef
Mientki wrote:

  

- Pyscripter 110 sec ( PyScripter is the default IDE I use now)
- Delphi  20 .. 35 sec
- Findstr  4 sec



What order did you try try them in? Did you try each one more than once, in
different orders? Just to rule out filesystem caching effects.

  

I repeated all of them at least twice, to see if I got the same result.
And indeed the very first run (PyScripter)  was about 150 sec.
So I think the above mentioned values give a good impression, nothing more.

I'm really amazed by the speed of Python !!
It can only be beaten by findstr, which is only available on windows.



Did you try find -exec grep -F?
  

well my windows version doesn't understand that :

P:\Python>find /?
Searches for a text string in a file or files.

FIND [/V] [/C] [/N] [/I] [/OFF[LINE]] "string" [[drive:][path]filename[ 
...]]


 /V Displays all lines NOT containing the specified string.
 /C Displays only the count of lines containing the string.
 /N Displays line numbers with the displayed lines.
 /I Ignores the case of characters when searching for the string.
 /OFF[LINE] Do not skip files with offline attribute set.
 "string"   Specifies the text string to find.
 [drive:][path]filename
Specifies a file or files to search.

If a path is not specified, FIND searches the text typed at the prompt
or piped from another command.

cheers,
Stef


--
http://mail.python.org/mailman/listinfo/python-list
  


--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[r0g]

[EMAIL PROTECTED] wrote:
> Lawrence D'Oliveiro:
>>> Gnuplot is non-Free software.
> 
> Fly Away:
>> Yes, it is.
> 
> From:
> http://www.gnuplot.info/faq/faq.txt
> 
> 1.7 Does gnuplot have anything to do with the FSF and the GNU project?
>[...]
>Gnuplot is freeware in the sense that you don't have to pay for it.
> However
>it is not freeware in the sense that you would be allowed to
> distribute a
>modified  version  of  your gnuplot freely. [...]
> 
> Bye,
> bearophile


Well, ish.  You can only distribute modifications to gnuplot itself as
patches, but you can distribute it freely and they publish the source
so, while it's not GPL free it's tending towards it.

Roger.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python is slow?

[Victor Prosolin]

[EMAIL PROTECTED] wrote:
> Lawrence D'Oliveiro:
>>> Gnuplot is non-Free software.
> 
> Fly Away:
>> Yes, it is.
> 
> From:
> http://www.gnuplot.info/faq/faq.txt
> 
> 1.7 Does gnuplot have anything to do with the FSF and the GNU project?
>[...]
>Gnuplot is freeware in the sense that you don't have to pay for it.
> However
>it is not freeware in the sense that you would be allowed to
> distribute a
>modified  version  of  your gnuplot freely. [...]

Yes, I did read this prior to posting.

Victor.
--
http://mail.python.org/mailman/listinfo/python-list