Re: python response slow when running external DLL

[jfong]

Peter Otten at 2015/12/1  UTC+8 7:01:55PM wrote：
> While the var_status.set() invoked from the second thread modifies some 
> internal data the main thread could kick in and modify (parts of) that same 
> data, thus bringing tkinter into an broken state. A simple example that 
> demonstrates the problem:
> 
> import random
> import threading
> import time
> 
> account = 70
> 
> def withdraw(delay, amount):
> global account
> if account >= amount:
> print("withdrawing", amount)
> account -= amount
> else:
> print("failed to withdraw", amount)
> 
> threads = []
> for i in range(10):
> t = threading.Thread(
> target=withdraw,
> kwargs=dict(delay=.1,
> amount=random.randrange(1, 20)))
> threads.append(t)
> t.start()
> 
> for t in threads:
> t.join()

It's a simple and vivid example. You must be in the banking business:-)

In this exercise, I can just use update_idletasks() method to solve the 
deferred display problem of tkinter, and forget all about thread. But what if I 
really want to use thread for the long-running DLL function in the download 
hander? I didn't figure out a correct way of doing it at this moment. Maybe 
queue is the answer but I am not familiar with it yet.

def download():
var_status.set(...)  #showing a start-up message
result = SayHello()  #this is a long-running function
if result#according to the result, display more messages

> 
> Before every withdrawal there seems to be a check that ensures that there is 
> enough money left, but when you run the script a few times you will still 
> sometimes end with a negative balance. That happens when thread A finds 
> enough money, then execution switches to thread B which also finds enough 
> money, then both threads perform a withdrawal -- oops there wasn't enough 
> money for both.
>  
> >> Another complication that inevitably comes with concurrency: what if the
> >> user triggers another download while one download is already running? If
> >> you don't keep track of all downloads the message will already switch to
> >> "Download OK" while one download is still running.
> > 
> > Hummm...this thought never comes to my mind. After take a quick test I
> > found, you are right, a second "download" was triggered immediately.
> > That's a shock to me. I suppose the same event shouldn't be triggered
> > again, or at least not triggered immediately, before its previous handler
> > was completed. ...I will take a check later on Borland C++ builder to see
> > how it reacts!
> > 
> > Anyway to prevent this happens? if Python didn't take care it for us.
> 
> A simple measure would be to disable the button until the download has 
> ended.

Good! simple and work.

I shouldn't say "Python should take care of it", but "tk" should do. It's 
annoying the widget's command was re-triggered before it was finished. (my 
personal opinion:-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python response slow when running external DLL

[Peter Otten]

jf...@ms4.hinet.net wrote:

> Peter Otten at 2015/11/28 UTC+8 6:14:09PM wrote：
>> No, the point of both recipes is that tkinter operations are only ever
>> invoked from the main thread. The main thread has polling code that
>> repeatedly looks if there are results from the helper thread. As far I
>> understand the polling method has the structure
>> 
>> f():
>># did we get something back from the other thread?
>># a queue is used to avoid race conditions
>> 
>># if yes react.
>># var_status.set() goes here
>> 
>># reschedule f to run again in a few millisecs;
>># that's what after() does
> 
> Have no idea how the main thread poll on all those events (or it use a
> queue)? All I know now is that the main thread(mainloop()?) can be easily
> blocked by event handlers if the handler didn't run as a separate thread.
> 
>> > .
>> > .
>> > #do the rest
>> > var_status.set('Download...')
>> > _thread.start_new_thread(td_download, ())  #must use threading
>> > 
>> > def td_download():
>> > result = mydll.SayHello()
>> > if result:
>> > var_status.set("Download Fail at %s" % hex(result))
>> > showerror('Romter', 'Download Fail')
>> > else:
>> > var_status.set('Download OK')
>> > showinfo('Romter', 'Download OK')
>> 
>> As td_download() runs in the other thread the var_status.set() methods
>> are problematic.
> 
> No idea what kind of problem it will encounter. Can you explain?

While the var_status.set() invoked from the second thread modifies some 
internal data the main thread could kick in and modify (parts of) that same 
data, thus bringing tkinter into an broken state. A simple example that 
demonstrates the problem:

import random
import threading
import time

account = 70

def withdraw(delay, amount):
global account
if account >= amount:
print("withdrawing", amount)
account -= amount
else:
print("failed to withdraw", amount)

threads = []
for i in range(10):
t = threading.Thread(
target=withdraw,
kwargs=dict(delay=.1,
amount=random.randrange(1, 20)))
threads.append(t)
t.start()

for t in threads:
t.join()

Before every withdrawal there seems to be a check that ensures that there is 
enough money left, but when you run the script a few times you will still 
sometimes end with a negative balance. That happens when thread A finds 
enough money, then execution switches to thread B which also finds enough 
money, then both threads perform a withdrawal -- oops there wasn't enough 
money for both.
 
>> Another complication that inevitably comes with concurrency: what if the
>> user triggers another download while one download is already running? If
>> you don't keep track of all downloads the message will already switch to
>> "Download OK" while one download is still running.
> 
> Hummm...this thought never comes to my mind. After take a quick test I
> found, you are right, a second "download" was triggered immediately.
> That's a shock to me. I suppose the same event shouldn't be triggered
> again, or at least not triggered immediately, before its previous handler
> was completed. ...I will take a check later on Borland C++ builder to see
> how it reacts!
> 
> Anyway to prevent this happens? if Python didn't take care it for us.

A simple measure would be to disable the button until the download has 
ended.

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

Re: python response slow when running external DLL

[jfong]

jf...@ms4.hinet.net at 2015/11/29  UTC+8 10:55:28AM wrote：
> > > .
> > > .
> > > #do the rest
> > > var_status.set('Download...')
> > > _thread.start_new_thread(td_download, ())  #must use threading
> > > 
> > > def td_download():
> > > result = mydll.SayHello()
> > > if result:
> > > var_status.set("Download Fail at %s" % hex(result))
> > > showerror('Romter', 'Download Fail')
> > > else:
> > > var_status.set('Download OK')
> > > showinfo('Romter', 'Download OK')
> > 
> > As td_download() runs in the other thread the var_status.set() methods are 
> > problematic.
> 
> No idea what kind of problem it will encounter. Can you explain?

It might be not a good idea to update GUI in a spawned thread, according to 
Mark Lutz's book "Programming Python", section "Using Threads with tkinter GUIs"

"If you do use threads in tkinter programs, however, you need to remember that 
only the main thread (the one that built the GUI and started the mainloop) 
should generally make GUI calls. At the least, multiple threads should not 
attempt to update the GUI at the same time..." 
 
> > Another complication that inevitably comes with concurrency: what if the 
> > user triggers another download while one download is already running? If 
> > you 
> > don't keep track of all downloads the message will already switch to 
> > "Download OK" while one download is still running.
> 
> Hummm...this thought never comes to my mind. After take a quick test I found, 
> you are right, a second "download" was triggered immediately. That's a shock 
> to me. I suppose the same event shouldn't be triggered again, or at least not 
> triggered immediately, before its previous handler was completed. ...I will 
> take a check later on Borland C++ builder to see how it reacts!
> 
> Anyway to prevent this happens? if Python didn't take care it for us.

then don't use thread if you prefer the GUI freeze.

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

Re: python response slow when running external DLL

[Laura Creighton]

In a message of Sat, 28 Nov 2015 11:13:38 +0100, Peter Otten writes:
>jf...@ms4.hinet.net wrote:
>> Using thread is obviously more logical. I think my mistake was the "while
>> busy:  pass" loop which makes no sense because it blocks the main thread,
>> just as the time.sleep() does. That's why in your link (and Laura's too)
>> the widget.after() scheduling was used for this purpose.

I never saw the reply that Peter is replying to.
The threading module constructs a higher level interface on top of the
low level thread module.  Thus it is the preferred way to go for
standard Python code -- and even Fredrik's recipe contains the
line:
import thread # should use the threading module instead!

Laura

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

Re: python response slow when running external DLL

[Peter Otten]

jf...@ms4.hinet.net wrote:

> Peter Otten at 2015/11/27 UTC+8 8:20:54PM wrote：
> 
>> Quick-fix example:
>> def download():
>> var.set("Starting download...")
>> root.update_idletasks()
>> time.sleep(3)
>> var.set("... done")
> 
> Thanks, Peter, The update_idletasks() works. In my trivial program it's
> easy to apply for there are only two places call the DLL function.
> 
>> A cleaner solution can indeed involve threads; you might adapt the
>> approach from  (Python 2
>> code).
> 
> Using thread is obviously more logical. I think my mistake was the "while
> busy:  pass" loop which makes no sense because it blocks the main thread,
> just as the time.sleep() does. That's why in your link (and Laura's too)
> the widget.after() scheduling was used for this purpose.

No, the point of both recipes is that tkinter operations are only ever 
invoked from the main thread. The main thread has polling code that 
repeatedly looks if there are results from the helper thread. As far I 
understand the polling method has the structure

f():
   # did we get something back from the other thread?
   # a queue is used to avoid race conditions

   # if yes react.
   # var_status.set() goes here

   # reschedule f to run again in a few millisecs; 
   # that's what after() does
 
> From what I had learned here, the other way I can do is making the codes
> modified as follows. It will get ride of the "result" and "busy" global
> variables, but it also makes the codes looks a little ugly. I think I will
> take the update_idletasks() way in this porting for it seems more simpler,
> and can be used on thread or non-thread calling. Thank you again.
> .
> .
> #do the rest
> var_status.set('Download...')
> _thread.start_new_thread(td_download, ())  #must use threading
> 
> def td_download():
> result = mydll.SayHello()
> if result:
> var_status.set("Download Fail at %s" % hex(result))
> showerror('Romter', 'Download Fail')
> else:
> var_status.set('Download OK')
> showinfo('Romter', 'Download OK')

As td_download() runs in the other thread the var_status.set() methods are 
problematic.

Another complication that inevitably comes with concurrency: what if the 
user triggers another download while one download is already running? If you 
don't keep track of all downloads the message will already switch to 
"Download OK" while one download is still running.

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

Re: python response slow when running external DLL

[jfong]

Peter Otten at 2015/11/28 UTC+8 6:14:09PM wrote：
> No, the point of both recipes is that tkinter operations are only ever 
> invoked from the main thread. The main thread has polling code that 
> repeatedly looks if there are results from the helper thread. As far I 
> understand the polling method has the structure
> 
> f():
># did we get something back from the other thread?
># a queue is used to avoid race conditions
> 
># if yes react.
># var_status.set() goes here
> 
># reschedule f to run again in a few millisecs; 
># that's what after() does

Have no idea how the main thread poll on all those events (or it use a queue)?
All I know now is that the main thread(mainloop()?) can be easily blocked by 
event handlers if the handler didn't run as a separate thread.

> > .
> > .
> > #do the rest
> > var_status.set('Download...')
> > _thread.start_new_thread(td_download, ())  #must use threading
> > 
> > def td_download():
> > result = mydll.SayHello()
> > if result:
> > var_status.set("Download Fail at %s" % hex(result))
> > showerror('Romter', 'Download Fail')
> > else:
> > var_status.set('Download OK')
> > showinfo('Romter', 'Download OK')
> 
> As td_download() runs in the other thread the var_status.set() methods are 
> problematic.

No idea what kind of problem it will encounter. Can you explain?

> Another complication that inevitably comes with concurrency: what if the 
> user triggers another download while one download is already running? If you 
> don't keep track of all downloads the message will already switch to 
> "Download OK" while one download is still running.

Hummm...this thought never comes to my mind. After take a quick test I found, 
you are right, a second "download" was triggered immediately. That's a shock to 
me. I suppose the same event shouldn't be triggered again, or at least not 
triggered immediately, before its previous handler was completed. ...I will 
take a check later on Borland C++ builder to see how it reacts!

Anyway to prevent this happens? if Python didn't take care it for us.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python response slow when running external DLL

[jfong]

Laura Creighton at 2015/11/28 UTC+8 6:52:25PM wrote：
> I never saw the reply that Peter is replying to.
> The threading module constructs a higher level interface on top of the
> low level thread module.  Thus it is the preferred way to go for
> standard Python code -- and even Fredrik's recipe contains the
> line:
>   import thread # should use the threading module instead!
> 
> Laura
Hi! Laura, 

takes the porting of an old BCB GUI program as an exercise in my learning 
python, I just quickly grab the required tools (mainly the tkinter) in python 
to complete this "work" and get a feeling of how python performs on doing this. 
Most of my knowledge of python comes from Mark Lutz's book "Learning python" 
and "Programming python". I didn't dive into this language deeply yet. There 
are topics about "_thread" and "threading" modules in the book and I just pick 
the lower level one for this because the "threading" is based on the "_thread".

Thanks for your note and link.

--Jach


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

Re: python response slow when running external DLL

[jfong]

Peter Otten at 2015/11/27  UTC+8 5:19:17 PM wrote：

Hi! Peter, thanks for your prompt reply.

> What does var_status.set() do? If it writes to stdout you may just need to 
> flush().

   var_status is a StringVar which binds to a lable's textvariable. I use this 
label as the status bar to show message.

> Do you see the same behaviour when you replace mydll.SayHello() with 
> something simple like time.sleep(1)?

I use time.sleep(3) to replace mydll.SayHello(), still get the same.

> As a general remark keep your test scripts as simple as possible. Example: 
> If 
> 
> import mydll
> print("Download...", end="")
> mydll.SayHello()
> print("OK")
> 
> showed the same behaviour it would be the ideal test script.

I run the above statements in a test file, it works as expected. I can see 
"Download..." and then "OK".


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

Re: python response slow when running external DLL

[Laura Creighton]

In a message of Fri, 27 Nov 2015 13:20:03 +0100, Peter Otten writes:

>A cleaner solution can indeed involve threads; you might adapt the approach 
>from  (Python 2 code).

But it is probably better to use threading

http://code.activestate.com/recipes/82965-threads-tkinter-and-asynchronous-io/

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python response slow when running external DLL

[Peter Otten]

jf...@ms4.hinet.net wrote:

> Peter Otten at 2015/11/27  UTC+8 5:19:17 PM wrote：
> 
> Hi! Peter, thanks for your prompt reply.
> 
>> What does var_status.set() do? If it writes to stdout you may just need
>> to flush().
> 
>var_status is a StringVar which binds to a lable's textvariable. I use
>this label as the status bar to show message.

Can I conclude from the above that you are using tkinter? Widgets can only 
update when the event loop gets a chance to run. While a quick fix is to 
invoke update_idletasks() callbacks shouldn't generally contain long-running 
code that -- as you have seen -- will block the complete user interface.
 
>> Do you see the same behaviour when you replace mydll.SayHello() with
>> something simple like time.sleep(1)?
> 
> I use time.sleep(3) to replace mydll.SayHello(), still get the same.
> 
>> As a general remark keep your test scripts as simple as possible.
>> Example: If
>> 
>> import mydll
>> print("Download...", end="")
>> mydll.SayHello()
>> print("OK")
>> 
>> showed the same behaviour it would be the ideal test script.
> 
> I run the above statements in a test file, it works as expected. I can
> see "Download..." and then "OK".
> 
> 

Quick-fix example:

#!/usr/bin/env python3
import tkinter as tk
import time

def download():
var.set("Starting download...")
root.update_idletasks()
time.sleep(3)
var.set("... done")


root = tk.Tk()
var = tk.StringVar()
label = tk.Label(root, textvariable=var)
label.pack()
button = tk.Button(root, text="Download", command=download)
button.pack()

root.mainloop()

A cleaner solution can indeed involve threads; you might adapt the approach 
from  (Python 2 code).


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

Re: python response slow when running external DLL

[jfong]

Peter Otten at 2015/11/27 UTC+8 8:20:54PM wrote：

> Quick-fix example:
> def download():
> var.set("Starting download...")
> root.update_idletasks()
> time.sleep(3)
> var.set("... done")

Thanks, Peter, The update_idletasks() works. In my trivial program it's easy to 
apply for there are only two places call the DLL function.

> A cleaner solution can indeed involve threads; you might adapt the approach 
> from  (Python 2 code).

Using thread is obviously more logical. I think my mistake was the "while busy: 
 pass" loop which makes no sense because it blocks the main thread, just as the 
time.sleep() does. That's why in your link (and Laura's too) the widget.after() 
scheduling was used for this purpose.

From what I had learned here, the other way I can do is making the codes 
modified as follows. It will get ride of the "result" and "busy" global 
variables, but it also makes the codes looks a little ugly. I think I will take 
the update_idletasks() way in this porting for it seems more simpler, and can 
be used on thread or non-thread calling. Thank you again.
.
.
#do the rest
var_status.set('Download...')
_thread.start_new_thread(td_download, ())  #must use threading

def td_download():
result = mydll.SayHello()
if result:
var_status.set("Download Fail at %s" % hex(result))
showerror('Romter', 'Download Fail')
else:
var_status.set('Download OK')
showinfo('Romter', 'Download OK')

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

Re: python response slow when running external DLL

[Peter Otten]

jf...@ms4.hinet.net wrote:

> I am new to Python. As an exercise of it, I try to port a program which
> was written more than 10 years ago. This program use the Borland C++
> Builder as its GUI front end and a DLL does the real work(it will takes a
> few seconds to complete). I saw a strange phenomenon in the following
> codes. The "var_status.set('Download...')" statement seems was deferred
> and didn't show up until the external DLL job was finished and I can only
> saw the result of "var_status.set('Download OK')" statement which
> immediately follows. I try to do the DLL function in a thread(selected by
> using the "test" flag in codes), but it didn't help.
> 
> Can anyone tell me what's the point I was missed?

What does var_status.set() do? If it writes to stdout you may just need to 
flush().

Do you see the same behaviour when you replace mydll.SayHello() with 
something simple like time.sleep(1)?

> -
> def download():
> global iniFilename
> if test:  global result, busy
> ini = iniFilename
> iniFilename = "c:\\$$temp.in3"
> saveIniFile()
> iniFilename = ini
> #do the rest
> var_status.set('Download...')
> if not test:
> result = mydll.SayHello()
> else:
> busy = True
> _thread.start_new_thread(td_download, ())
> while busy:  pass
> if result:
> var_status.set("Download Fail at %s" % hex(result))
> showerror('Romter', 'Download Fail')
> else:
> var_status.set('Download OK')
> showinfo('Romter', 'Download OK')
> 
> if test:
> result = 0x
> busy = True
> def td_download():
> global busy, result
> result = mydll.SayHello()
> busy = False
> --

As a general remark keep your test scripts as simple as possible. Example: 
If 

import mydll
print("Download...", end="")
mydll.SayHello()
print("OK")

showed the same behaviour it would be the ideal test script.

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

python response slow when running external DLL

[jfong]

I am new to Python. As an exercise of it, I try to port a program which was 
written more than 10 years ago. This program use the Borland C++ Builder as its 
GUI front end and a DLL does the real work(it will takes a few seconds to 
complete). I saw a strange phenomenon in the following codes. The 
"var_status.set('Download...')" statement seems was deferred and didn't show up 
until the external DLL job was finished and I can only saw the result of 
"var_status.set('Download OK')" statement which immediately follows. I try to 
do the DLL function in a thread(selected by using the "test" flag in codes), 
but it didn't help.

Can anyone tell me what's the point I was missed?

-
def download():
global iniFilename
if test:  global result, busy
ini = iniFilename
iniFilename = "c:\\$$temp.in3"
saveIniFile()
iniFilename = ini
#do the rest
var_status.set('Download...')
if not test:
result = mydll.SayHello()
else:
busy = True
_thread.start_new_thread(td_download, ())
while busy:  pass
if result:
var_status.set("Download Fail at %s" % hex(result))
showerror('Romter', 'Download Fail')
else:
var_status.set('Download OK')
showinfo('Romter', 'Download OK')

if test:
result = 0x
busy = True
def td_download():
global busy, result
result = mydll.SayHello()
busy = False
--

Best Regards,
Jach
-- 
https://mail.python.org/mailman/listinfo/python-list

embedded python 2.7.1 slow startup

[bruce bushby]

Hi

I've been playing with running python on embedded linux. I thought I would
run some straces to see how the install went when I noticed python
attempts to open
loads of files that don't exist.is there a way to prevent these open
attemptsthey're responsible for 40% of my scripts execution time.

I was wondering if there is a way to prevent python from attempting to open
files I know are not there?


Thanks
Bruce




# strace -ce trace=open ./fib.py
1 1 2 3 5 8 13 21 34 55 89 144
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
100.000.020306 128   159   118 open
-- --- --- - - 
100.000.020306   159   118 total
# strace -fe trace=open ./fib.py
open(/dev/urandom, O_RDONLY)  = 3
open(/lib/libpthread.so.0, O_RDONLY)  = 3
open(/lib/libdl.so.0, O_RDONLY)   = 3
open(/lib/libutil.so.0, O_RDONLY) = 3
open(/lib/libm.so.0, O_RDONLY)= 3
open(/lib/libc.so.0, O_RDONLY)= 3
open(/lib/libc.so.0, O_RDONLY)= 3
open(/lib/libc.so.0, O_RDONLY)= 3
open(/lib/libc.so.0, O_RDONLY)= 3
open(/lib/libc.so.0, O_RDONLY)= 3
open(/usr/lib/python2.7/site.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/sitemodule.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/site.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/site.pyc, O_RDONLY|O_LARGEFILE) = 3
open(/usr/lib/python2.7/os.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
open(/usr/lib/python2.7/osmodule.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/os.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
open(/usr/lib/python2.7/os.pyc, O_RDONLY|O_LARGEFILE) = 4
open(/usr/lib/python2.7/posixpath.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/posixpathmodule.so, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open(/usr/lib/python2.7/posixpath.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/posixpath.pyc, O_RDONLY|O_LARGEFILE) = 5
open(/usr/lib/python2.7/stat.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/statmodule.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/stat.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/stat.pyc, O_RDONLY|O_LARGEFILE) = 6
open(/usr/lib/python2.7/genericpath.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/genericpathmodule.so, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open(/usr/lib/python2.7/genericpath.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/genericpath.pyc, O_RDONLY|O_LARGEFILE) = 6
open(/usr/lib/python2.7/warnings.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/warningsmodule.so, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open(/usr/lib/python2.7/warnings.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/warnings.pyc, O_RDONLY|O_LARGEFILE) = 6
open(/usr/lib/python2.7/linecache.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/linecachemodule.so, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open(/usr/lib/python2.7/linecache.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/linecache.pyc, O_RDONLY|O_LARGEFILE) = 7
open(/usr/lib/python2.7/types.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/typesmodule.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open(/usr/lib/python2.7/types.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/types.pyc, O_RDONLY|O_LARGEFILE) = 7
open(/usr/lib/python2.7/UserDict.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/UserDictmodule.so, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open(/usr/lib/python2.7/UserDict.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/UserDict.pyc, O_RDONLY|O_LARGEFILE) = 5
open(/usr/lib/python2.7/_abcoll.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/_abcollmodule.so, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
open(/usr/lib/python2.7/_abcoll.py, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/usr/lib/python2.7/_abcoll.pyc, O_RDONLY|O_LARGEFILE) = 6
open(/usr/lib/python2.7/abc.so, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)

Re: embedded python 2.7.1 slow startup

[Kushal Kumaran]

On Tue, Mar 8, 2011 at 2:36 PM, bruce bushby bruce.bus...@gmail.com wrote:
 Hi
 I've been playing with running python on embedded linux. I thought I would
 run some straces to see how the install went when I noticed python
 attempts to open
 loads of files that don't exist.is there a way to prevent these open
 attemptsthey're responsible for 40% of my scripts execution time.
 I was wondering if there is a way to prevent python from attempting to open
 files I know are not there?


I had a (sort of) similar problem recently with a python script on an
N900 phone, with the startup time completely dominating the total
runtime.

I simply converted it into daemon instead, which solved the
responsiveness problem for me.  I wonder if that is applicable for
your situation.

-- 
regards,
kushal
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: embedded python 2.7.1 slow startup

[Terry Reedy]

On 3/8/2011 4:06 AM, bruce bushby wrote:

Hi

I've been playing with running python on embedded linux. I thought I
would run some straces to see how the install went when I noticed
python attempts to open
loads of files that don't exist.is there a way to prevent these
open attemptsthey're responsible for 40% of my scripts execution time.

I was wondering if there is a way to prevent python from attempting to
open files I know are not there?


The problem is that *python* does not know. Most of the failed attempts 
are from looking for a compiled shared library version of every module 
to be imported. I wonder if it would be faster to make a set with all 
shared library names and check that instead before going to the file 
system. On an embedded system, especially, something might even be built 
into the binary or read at startup.


--
Terry Jan Reedy

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

Re: Python is slow?

[José Matos]

On Monday 06 October 2008 00:01:50 Lawrence D'Oliveiro wrote:
 Not listed as one
 http://www.fsf.org/licensing/licenses/index_html/view?searchterm=license.

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

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

Re: Python 3.0 slow file IO

[thomasvang...@gmail.com]

Thanks a lot for all the responses. I'll move back to Python 2.5 for
compatibility with SciPY and some other third party packages.
I'll leave the compilation process for some other day, for now I'm a
happy user, mayve In the future I would like to contribute to the
developmental process..
--
http://mail.python.org/mailman/listinfo/python-list

Python 3.0 slow file IO

[thomasvang...@gmail.com]

I just recently learned python, I'm using it mainly to process huge
5GB txt files of ASCII information about DNA. I've decided to learn
3.0, but maybe I need to step back to 2.6?

I'm getting exceedingly frustrated by the slow file IO behaviour of
python 3.0. I know that a bug-report was submitted here:
http://bugs.python.org/issue4533. And a solution was posted.
However, i don't know how to apply this patch. I've searched the
forums and tried:
C:\python30 patch -p0  fileio_buffer.patch
The patch command is not recognized..

Any help on implementing this patch, or advice on moving back to the
older version is appreciated.
Kind regards,
Thomas
--
http://mail.python.org/mailman/listinfo/python-list

Re: Python 3.0 slow file IO

[Ulrich Eckhardt]

thomasvang...@gmail.com wrote:
 C:\python30 patch -p0  fileio_buffer.patch
 The patch command is not recognized..

You need the 'patch' program first. Further, you will need a C compiler. If
you don't know how to compile from sources, I would postpone patching
sources to after learning that.

 [...] advice on moving back to the older version is appreciated.

Just install the latest 2.6 release. I think you can easily install it
alongside 3.0, all you need to pay attention to is the PATH environment
variable.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

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

Re: Python 3.0 slow file IO

[Christian Heimes]

thomasvang...@gmail.com schrieb:
 I just recently learned python, I'm using it mainly to process huge
 5GB txt files of ASCII information about DNA. I've decided to learn
 3.0, but maybe I need to step back to 2.6?
 
 I'm getting exceedingly frustrated by the slow file IO behaviour of
 python 3.0. I know that a bug-report was submitted here:
 http://bugs.python.org/issue4533. And a solution was posted.
 However, i don't know how to apply this patch. I've searched the
 forums and tried:
 C:\python30 patch -p0  fileio_buffer.patch
 The patch command is not recognized..

You need the Python sources, a patch utility and Microsoft Visual Studio
2008 in order to compile Python yourself.
 
 Any help on implementing this patch, or advice on moving back to the
 older version is appreciated.

I suggest you stick with Python 2.5 or 2.6. Python 3.0 isn't as mature
as the 2.x series. It's brand new, lot's of things have changed, too.

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

Re: Python 3.0 slow file IO

[rdmurray]

Quoth Christian Heimes li...@cheimes.de:
 thomasvang...@gmail.com schrieb:
  I just recently learned python, I'm using it mainly to process huge
  5GB txt files of ASCII information about DNA. I've decided to learn
  3.0, but maybe I need to step back to 2.6?
  
  I'm getting exceedingly frustrated by the slow file IO behaviour of
  python 3.0. I know that a bug-report was submitted here:
  http://bugs.python.org/issue4533. And a solution was posted.
[snip stuff about patching]
 
 I suggest you stick with Python 2.5 or 2.6. Python 3.0 isn't as mature
 as the 2.x series. It's brand new, lot's of things have changed, too.

3.1 will come out much sooner than a normal next dot release python
would, and will contain very significant improvements in the IO speed.
In the meantime, in your case at least, to get real work done you'll
be better off using 2.6.  You can use the 'from __future__ import' to
bring various 3.0 features into 2.6 and make 2.6 look more like 3.0,
and you can use the -3 flag to check your code for 3.0 compatibility, so
that you will be ready to move back to the 3 series when 3.1 comes out.
(Assuming you don't end up needing any 3rd party libraries that haven't
been ported yet by then, that is.)

Unless, of course, you are comfortable with compiling from source
and would like to help _test_ the 3.1 IO library :)

--RDM

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

Re: Python is slow

[Lou Pecora]

In article mailman.5967.1229898197.3487.python-l...@python.org,
 James Mills prolo...@shortcircuit.net.au 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 Im 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

[cm_gui]

On Dec 22, 6:51 am, Lou Pecora pec...@anvil.nrl.navy.mil wrote:
 In article mailman.5967.1229898197.3487.python-l...@python.org,
  James Mills prolo...@shortcircuit.net.au 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 Im 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

[Luis M . González]

On Dec 22, 3:42 pm, cm_gui cmg...@gmail.com 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

[James Mills]

On Tue, Dec 23, 2008 at 4:42 AM, cm_gui cmg...@gmail.com 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

[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

[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

[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

[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

[Luis M . González]

On Dec 21, 2:34 pm, r rt8...@gmail.com 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]

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

[James Mills]

On Mon, Dec 22, 2008 at 4:47 AM, r rt8...@gmail.com 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 Im wrong)
it's also used by NASA.

--JamesMills
--
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

[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

[RadicalEd]

On Dec 10, 1:42 pm, cm_gui cmg...@gmail.com 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

[Craig Allen]

On Dec 14, 6:38 pm, cm_gui cmg...@gmail.com 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

[r]

On Dec 15, 7:15 am, Luis M. González luis...@gmail.com wrote:
 On Dec 15, 1:38 am, cm_gui cmg...@gmail.com 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

[James Mills]

n Wed, Dec 17, 2008 at 8:24 AM, r rt8...@gmail.com 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

[Stef Mientki]

r wrote:

On Dec 15, 7:15 am, Luis M. González luis...@gmail.com wrote:
  

On Dec 15, 1:38 am, cm_gui cmg...@gmail.com 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

[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

[James Mills]

On Wed, Dec 17, 2008 at 9:08 AM, r rt8...@gmail.com 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]

On Dec 16, 5:47 pm, James Mills prolo...@shortcircuit.net.au
wrote:
 On Wed, Dec 17, 2008 at 9:08 AM, r rt8...@gmail.com 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

[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

[James Mills]

On Mon, Dec 15, 2008 at 5:26 PM, Andreas Kostyrka andr...@kostyrka.org 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

[George Sakkis]

On Dec 15, 8:15 am, Luis M. González luis...@gmail.com wrote:
 On Dec 15, 1:38 am, cm_gui cmg...@gmail.com 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 cmg...@gmail.com 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

[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

[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 Sun, Dec 14, 2008 at 11:38 PM, cm_gui cmg...@gmail.com 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

[James Mills]

On Mon, Dec 15, 2008 at 2:44 PM, Benjamin Kaplan
benjamin.kap...@case.edu wrote:
 On Sun, Dec 14, 2008 at 11:38 PM, cm_gui cmg...@gmail.com 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

[James Mills]

On Mon, Dec 15, 2008 at 2:59 PM, James Mills
prolo...@shortcircuit.net.au wrote:
 On Mon, Dec 15, 2008 at 2:44 PM, Benjamin Kaplan
 benjamin.kap...@case.edu wrote:
 On Sun, Dec 14, 2008 at 11:38 PM, cm_gui cmg...@gmail.com 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

[Andreas Kostyrka]

Am Sun, 14 Dec 2008 20:38:58 -0800 (PST)
schrieb cm_gui cmg...@gmail.com:

 
 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

[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=alllang=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

[Isaac Gouy]

On Dec 12, 11:41 am, Bruno Desthuilliers
bdesth.quelquech...@free.quelquepart.fr 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=alllang=vwlang2=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

[sturlamolden]

On 10 Des, 19:42, cm_gui cmg...@gmail.com 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

[Benjamin Kaplan]

On Sat, Dec 13, 2008 at 3:35 PM, sturlamolden sturlamol...@yahoo.no wrote:

 On 10 Des, 19:42, cm_gui cmg...@gmail.com 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

[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

[sturlamolden]

On Dec 11, 4:25 am, Carl Banks pavlovevide...@gmail.com 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=alllang=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

[sturlamolden]

On Dec 12, 2:29 pm, sturlamolden sturlamol...@yahoo.no 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

[Luis M . González]

On Dec 12, 10:43 am, sturlamolden sturlamol...@yahoo.no wrote:
 On Dec 12, 2:29 pm, sturlamolden sturlamol...@yahoo.no 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, 3:04 pm, Luis M. González luis...@gmail.com 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

[David Cournapeau]

On Fri, Dec 12, 2008 at 11:04 PM, Luis M. González luis...@gmail.com 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:27 pm, David Cournapeau courn...@gmail.com 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

[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:43 pm, Stefan Behnel stefan...@behnel.de 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

[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=alllang=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

[MRAB]

sturlamolden wrote:

On Dec 12, 3:04 pm, Luis M. González luis...@gmail.com 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

[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

[Christian Heimes]

sturlamolden schrieb:
 On Dec 12, 3:04 pm, Luis M. González luis...@gmail.com 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

[Luis M . González]

On Dec 12, 11:17 am, sturlamolden sturlamol...@yahoo.no wrote:
 On Dec 12, 3:04 pm, Luis M. González luis...@gmail.com 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

[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

[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

[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

[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

[Giampaolo Rodola']

On 11 Dic, 13:06, Luis M. González luis...@gmail.com wrote:
 On Dec 10, 3:42 pm, cm_gui cmg...@gmail.com 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

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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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: 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=alllang=al
http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=all
http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=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

[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: 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

[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

[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

[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?

[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?

[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://www.fsf.org/licensing/licenses/index_html/view?searchterm=license.

--
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?

[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