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
In message [EMAIL PROTECTED], Stef
Mientki wrote:
Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], Stef
Mientki wrote:
I'm really amazed by the speed of Python !!
It can only be beaten by findstr, which is only available on windows.
Did you try find -exec grep -F?
well my
Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], r0g wrote:
You can only distribute modifications to gnuplot itself as
patches, but you can distribute it freely ...
This must be some new definition of freely of which I'm unaware.
As in beer.
--
In message [EMAIL PROTECTED], r0g wrote:
Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], r0g wrote:
You can only distribute modifications to gnuplot itself as
patches, but you can distribute it freely ...
This must be some new definition of freely of which I'm unaware.
As in
On Tue, 30 Sep 2008 14:50:26 +1300, Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], r0g wrote:
You can only distribute modifications to gnuplot itself as patches, but
you can distribute it freely ...
This must be some new definition of freely of which I'm unaware.
You're free to
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2008 14:50:26 +1300, Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], r0g wrote:
You can only distribute modifications to gnuplot itself as
patches, but you can distribute it freely ...
[…]
Where's the non-free bit?
On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2008 14:50:26 +1300, Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], r0g wrote:
You can only distribute modifications to gnuplot itself as patches,
but you can
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
You're not free to modify gnuplot and redistribute the result.
That you're free to distribute patches is nice, but it's not
enough to make the work free. The freedom to help people by giving
On 30 Sep, 14:19, Ben Finney [EMAIL PROTECTED]
wrote:
This is where the useful your freedom to swing your fist ends at the
tip of the other man's nose applies: As soon as the act you wish to
perform is restricting the freedom of another, you're not
contemplating an act of freedom, but an act
On Tue, 30 Sep 2008 22:19:57 +1000, Ben Finney wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
You're not free to modify gnuplot and redistribute the result.
That you're free to distribute patches is nice, but it's not enough
to
On Sep 30, 9:43 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Tue, 30 Sep 2008 22:19:57 +1000, Ben Finney wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2008 19:04:41 +1000, Ben Finney wrote:
You're not free to modify gnuplot and redistribute the
On Tuesday 30 September 2008 16:04:35 George Sakkis wrote:
What you're missing is that for Free Software (TM) zealots it's a
matter of philosophical principle, totally unrelated to how easy is to
overcome the restriction. There is not a practicality beats purity
clause in the FSF Bible.
The
Steven D'Aprano wrote:
On Tue, 30 Sep 2008 22:19:57 +1000, Ben Finney wrote:
I do, because a natural, beneficial act (modify the work and
redistribute it) that has no technical reason to restrict, is
artifically restricted.
We agree that the restriction is artificial, and I think irrational
Steven D'Aprano [EMAIL PROTECTED] writes:
I simply don't think that having to run some variation on
patch -i patchfile.patch
is a requirement so onerous that it makes the gnuplot licence
non-free. Perhaps I'm just more tolerant of eccentricities than you
:)
The distinction here is that
Terry Reedy [EMAIL PROTECTED] writes:
Steven D'Aprano wrote:
We agree that the restriction is artificial, and I think
irrational (although I'd be interested in hearing the gnuplot
developers' reasoning before making a final judgment).
I believe it is a matter of preserving clarity of
On Wed, 01 Oct 2008 09:06:08 +1000, Ben Finney wrote:
Terry Reedy [EMAIL PROTECTED] writes:
Steven D'Aprano wrote:
We agree that the restriction is artificial, and I think irrational
(although I'd be interested in hearing the gnuplot developers'
reasoning before making a final
Steven D'Aprano [EMAIL PROTECTED] writes:
On Wed, 01 Oct 2008 09:06:08 +1000, Ben Finney wrote:
Note that I consider a work free even if it fails to grant “the
right to distribute misrepresentations of the author's words”,
because that act is an exercise of undue power over another
In message
[EMAIL PROTECTED],
sturlamolden wrote:
... and possibility of interfacing with gnuplot ...
Gnuplot is non-Free software.
--
http://mail.python.org/mailman/listinfo/python-list
In message [EMAIL PROTECTED], Stef
Mientki wrote:
- Pyscripter 110 sec ( PyScripter is the default IDE I use now)
- Delphi 20 .. 35 sec
- Findstr 4 sec
What order did you try try them in? Did you try each one more than once, in
different orders? Just to rule out filesystem caching effects.
On Sep 29, 3:05 am, Lawrence D'Oliveiro [EMAIL PROTECTED]
central.gen.new_zealand wrote:
In message
[EMAIL PROTECTED],
sturlamolden wrote:
... and possibility of interfacing with gnuplot ...
Gnuplot is non-Free software.
Yes, it is.
Victor.
--
Lawrence D'Oliveiro:
Gnuplot is non-Free software.
Fly Away:
Yes, it is.
From:
http://www.gnuplot.info/faq/faq.txt
1.7 Does gnuplot have anything to do with the FSF and the GNU project?
[...]
Gnuplot is freeware in the sense that you don't have to pay for it.
However
it is not
[EMAIL PROTECTED] wrote:
Lawrence D'Oliveiro:
Gnuplot is non-Free software.
Fly Away:
Yes, it is.
From:
http://www.gnuplot.info/faq/faq.txt
1.7 Does gnuplot have anything to do with the FSF and the GNU project?
[...]
Gnuplot is freeware in the sense that you don't have to pay
[EMAIL PROTECTED] wrote:
Lawrence D'Oliveiro:
Gnuplot is non-Free software.
Fly Away:
Yes, it is.
From:
http://www.gnuplot.info/faq/faq.txt
1.7 Does gnuplot have anything to do with the FSF and the GNU project?
[...]
Gnuplot is freeware in the sense that you don't have to pay
Lawrence D'Oliveiro wrote:
In message [EMAIL PROTECTED], Stef
Mientki wrote:
- Pyscripter 110 sec ( PyScripter is the default IDE I use now)
- Delphi 20 .. 35 sec
- Findstr 4 sec
What order did you try try them in? Did you try each one more than once, in
different orders? Just to
In message [EMAIL PROTECTED], r0g wrote:
You can only distribute modifications to gnuplot itself as
patches, but you can distribute it freely ...
This must be some new definition of freely of which I'm unaware.
--
http://mail.python.org/mailman/listinfo/python-list
Hi !
Thanks for return.
Some infos: from a long time, I found that it's often more fast to use
windows's command, instead of develop in high level language (and also,
low level...)
FINDSTR is fast. OK. But internal commands are more fast. Example : DIR
(with all his options)
And it's
On Sep 26, 5:45 am, David Cournapeau [EMAIL PROTECTED] wrote:
I am fairly experienced in matlab (have been using it extensively for
5 years in academical context), and now with numpy, and generally,
they are comparable speed-wise. Matlab has some niceties which makes
it faster in some simple
Matlab's strongest side is data visualization though. Although we have
matplotlib, mayavi and possibility of interfacing with gnuplot, it's
not anywhere near the capabilities of Matlab.
What particular Matlab visualization features are you referring to? I
can't think of anything that would
+1 QOTW...
On Tue, Sep 23, 2008 at 7:13 AM, George Sakkis [EMAIL PROTECTED]wrote:
On Sep 23, 9:57 am, Grant Edwards [EMAIL PROTECTED] wrote:
On 2008-09-23, sturlamolden [EMAIL PROTECTED] wrote:
[...]
After having a working Python prototype, I resorted to rewrite the
program in
Mike Driscoll wrote:
On Sep 26, 8:35 am, Stef Mientki [EMAIL PROTECTED] wrote:
hello,
I want to search multiple textfiles (python source files) for a specific
word.
I can find all files, open them and do a search,
but I guess that will be rather slow.
I couldn't find any relevant
On Wed, Sep 24, 2008 at 3:07 AM, sturlamolden [EMAIL PROTECTED] wrote:
On Sep 23, 3:44 pm, Robert Singer [EMAIL PROTECTED] wrote:
Well, python is not a number crunching language. However much we would
like it to be (we would ? :-).
No scripting language is.
Not even Matlab, R, IDL, Octave,
In article [EMAIL PROTECTED],
Grant Edwards [EMAIL PROTECTED] wrote:
AFAICT, _everybody_ is bad at programming C++.
One begins to suspect it's not the fault of the programmers.
http://www.netfunny.com/rhf/jokes/98/May/stroustrup.html
--
Aahz ([EMAIL PROTECTED]) *
they
suggest Python as a possible language because of the 'Python is slow'
myth...
--
python -c print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])
--
http://mail.python.org/mailman/listinfo/python-list
For those who are interested:
I've updated the cookbook tutorial on the kd-tree:
http://scipy.org/Cookbook/KDTree
It now also includes parallel search for multicore CPUs
(multiprocessing standard module). Even if you are not genuinely
interested in kd-trees, it shows how to do parallel
I have updated the cookbook entry for yesterday to also include
parallel processing for large data sets. Even if you're not interested
in kd-trees, it is a good example of what the new multiprocessing
standard module can do. There are still people being scared by the
GIL, thinking it prevents
I have recently been playing with a kd-tree for solving the post
office problem in a 12-dimensional space. This is pure cpu bound
number crunching, a task for which I suspected Python to be
inefficient.
My prototype in Python 2.5 using NumPy required 0.41 seconds to
construct the tree from 50,000
On Tue, 23 Sep 2008 06:23:12 -0700 (PDT), sturlamolden
[EMAIL PROTECTED] wrote:
I have recently been playing with a kd-tree for solving the post
office problem in a 12-dimensional space. This is pure cpu bound
number crunching, a task for which I suspected Python to be
inefficient.
Well, python
On 2008-09-23, sturlamolden [EMAIL PROTECTED] wrote:
[...]
After having a working Python prototype, I resorted to rewrite the
program in C++. The Python prototype took an hour to make, debug and
verify. The same thing in C++ took me almost a day to complete, even
with a working prototype as
On Sep 23, 9:57 am, Grant Edwards [EMAIL PROTECTED] wrote:
On 2008-09-23, sturlamolden [EMAIL PROTECTED] wrote:
[...]
After having a working Python prototype, I resorted to rewrite the
program in C++. The Python prototype took an hour to make, debug and
verify. The same thing in C++
We may conclude that I'm bad at programming C++,
Grant AFAICT, _everybody_ is bad at programming C++.
Grant One begins to suspect it's not the fault of the programmers.
+1 QOTW...
Skip
--
http://mail.python.org/mailman/listinfo/python-list
sturlamolden:
CPython is generally slow (you can see this from the huge amount of
solutions invented to solve the speed problem, like Cython, Numpy,
Psyco, ShedSkin, Weave, Inline, SIP, Boost Python, SWIG, etc etc), but
for most of the usages Python is used for, it's not a significant
problem. I
On Sep 23, 3:44 pm, Robert Singer [EMAIL PROTECTED] wrote:
Well, python is not a number crunching language. However much we would
like it to be (we would ? :-).
No scripting language is.
Not even Matlab, R, IDL, Octave, SciLab, S-PLUS or Mathematica?
Before resorting to rewriting the
On Sep 23, 5:31 pm, [EMAIL PROTECTED] wrote:
Well written C++ code is generally faster or much faster than similar
Python code, but programming in Python is often simpler, and it
generally requires less time. So it may happen that to solve a problem
a Python program that runs in 1 hour that
On Sep 23, 10:57 am, Grant Edwards [EMAIL PROTECTED] wrote:
AFAICT, _everybody_ is bad at programming C++.
Thankfully, at least Numpy developers are not bad at C programming.
--
http://mail.python.org/mailman/listinfo/python-list
sturlamolden:
F# and OCaml look promising though.
I bet on the future of D and Haskell (and maybe Fortress) instead :-)
We'll see.
Sure I could show you the code, Python and C++, if I had a place to post it.
I think the Python version suffices. If it's not too much private you
may post the
On Sep 23, 8:52 pm, [EMAIL PROTECTED] wrote:
I think the Python version suffices. If it's not too much private you
may post the single minimal/reduced runnable Python module here, it
will be deleted in some time (if you want you can also use a private
paste):http://codepad.org/
[EMAIL PROTECTED] wrote:
sturlamolden:
Sure I could show you the code, Python and C++, if I had a place to post it.
I think the Python version suffices. If it's not too much private you
may post the single minimal/reduced runnable Python module here, it
will be deleted in some time (if you
On Sep 23, 8:31 am, [EMAIL PROTECTED] wrote:
Guys, this looks like a great data structure/algo for something I am
working on.
But... where do I find some definitions of the original BK-tree idea?
I looked through Amazon
and only a few books mention something like BK-Tree and these are
mostly
On Sep 23, 9:17 pm, Robert Kern [EMAIL PROTECTED] wrote:
You could also drop it on the scipy.org wiki in the Cookbook category.
Yes, if I could figure out how to use it...
--
http://mail.python.org/mailman/listinfo/python-list
J Peyret wrote:
On Sep 23, 8:31 am, [EMAIL PROTECTED] wrote:
Guys, this looks like a great data structure/algo for something I am
working on.
But... where do I find some definitions of the original BK-tree idea?
Uh, actually we're talking about kd-trees, not BK-trees. kd-trees are for
On Tue, 23 Sep 2008 11:07:22 -0700 (PDT), sturlamolden
[EMAIL PROTECTED] wrote:
On Sep 23, 3:44 pm, Robert Singer [EMAIL PROTECTED] wrote:
Well, python is not a number crunching language. However much we would
like it to be (we would ? :-).
No scripting language is.
Not even Matlab, R, IDL,
sturlamolden wrote:
On Sep 23, 9:17 pm, Robert Kern [EMAIL PROTECTED] wrote:
You could also drop it on the scipy.org wiki in the Cookbook category.
Yes, if I could figure out how to use it...
What's confusing? You do have to create a profile:
http://www.scipy.org/UserPreferences
--
On 23 Sep., 21:23, J Peyret [EMAIL PROTECTED] wrote:
On Sep 23, 8:31 am, [EMAIL PROTECTED] wrote:
Guys, this looks like a great data structure/algo for something I am
working on.
But... where do I find some definitions of the original BK-tree idea?
*geometric data structures*. Just google
On Sep 23, 10:05 pm, Robert Singer [EMAIL PROTECTED] wrote:
May I ask what are your main objections to it ?
1. gfortran is not Absoft.
2. If I program the same in C99 and Fortran 95, and compile with gcc
and gfortran, the C99 code runs a lot faster (I've only tested with
wavelet transforms).
On Sep 23, 10:16 pm, Robert Kern [EMAIL PROTECTED] wrote:
What's confusing? You do have to create a profile:
How do I add a new page to the wiki? I'm only able to edit the front
page of the cookbook. But it doesn't help to add link there if I have
no page to link. (I may be incredibly stupid
sturlamolden wrote:
On Sep 23, 10:16 pm, Robert Kern [EMAIL PROTECTED] wrote:
What's confusing? You do have to create a profile:
How do I add a new page to the wiki? I'm only able to edit the front
page of the cookbook. But it doesn't help to add link there if I have
no page to link. (I may
On Tue, 23 Sep 2008 13:34:10 -0700 (PDT), sturlamolden
[EMAIL PROTECTED] wrote:
1. gfortran is not Absoft.
I find this comment absurd. What did you mean by it ?
Yes, gfortran is not Absoft, just as red is not blue (?!).
I also don't understand whether you're looking for a free or a
commercial
On Sep 23, 8:52 pm, [EMAIL PROTECTED] wrote:
Is this a good or bad thing? ;-)
It seems we have been implementing different algorithms. kd-trees are
not BK-trees.
http://www.scipy.org/Cookbook/KDTree
--
http://mail.python.org/mailman/listinfo/python-list
Robert Kern wrote:
J Peyret wrote:
On Sep 23, 8:31 am, [EMAIL PROTECTED] wrote:
Guys, this looks like a great data structure/algo for something I am
working on.
But... where do I find some definitions of the original BK-tree idea?
Uh, actually we're talking about kd-trees, not BK-trees.
sturlamolden:
It seems we have been implementing different algorithms. kd-trees are
not BK-trees.
http://www.scipy.org/Cookbook/KDTree
Sorry for my silly mistake :-)
Note: in your code I don't know if the collections.deque data
structure may help (it's faster than list for appending), but I
On 22 May, 17:14, cm_gui [EMAIL PROTECTED] wrote:
Python is slow. Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so
On May 22, 7:14 pm, cm_gui [EMAIL PROTECTED] wrote:
Python is slow. Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so
That hardware battle was fought long ago. Von Neumann machine vs. the Lisp
machine. Guess who won?
http://en.wikipedia.org/wiki/Lisp_machine
It would be very hard to fight that war all over again.
Charlie
On Fri, Jun 6, 2008 at 4:59 PM, Jan Claeys [EMAIL PROTECTED] wrote:
Op Fri, 23 May
On May 24, 2008, at 1:56 AM, cm_gui wrote:
okay, maybe Python is only slightly slower than PHP,
but it APPEARS to be much slower.
there is a distinct waiting time whenever you access a python web page
before the page starts loading. but once it loads, it is fast.
php page starts loading
Op Fri, 23 May 2008 14:00:33 -0700, schreef [EMAIL PROTECTED]:
Now this I can tell is false. The problem is not that it's difficult to
make a native compiler for dynamic languages, the problem is that it's
difficult to write native compiler for dynamic languages that generates
code that beats
cm_gui [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
okay, maybe Python is only slightly slower than PHP,
but it APPEARS to be much slower.
there is a distinct waiting time whenever you access a python web page
before the page starts loading. but once it loads, it is fast.
On May 23, 2:50 pm, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
Brad a écrit :
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between.
I find it suitable for lots of stuff. I use C++ when performance really
matters tho... right
i am not comparing Python with C or C++ which are of course
compiled languages.
if there is any consolation to Python lovers here, Python is still
faster than Microsoft ASP/ASPX.
i'm not trying to 'troll' here. it's not just me.
many have complained that python is slow. python websites
On Fri, 23 May 2008 03:21:23 -0700, Ivan Illarionov
[EMAIL PROTECTED] wrote:
On 23 май, 02:20, Brad [EMAIL PROTECTED] wrote:
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between.
I find it suitable for lots of stuff. I use C++ when
Hallöchen!
cm_gui writes:
[...]
if python is such a good programming/scripting language,
why can't they build a faster interpreter/compiler engine?
and beat php and zend.
to the python team, rebuild your interpreter!
torontolife.com is slow.
For me, torontolife.com is exactly as fast as
.
Much slower than say, code.google.com, or the trac site I have running on my
remote server. I have seen just as many slow php sites as slow python
sites.
Also, the hosting solution plays a huge part in how fast a site responds.
If someone is using python through cgi, that IS going to be very slow
I love it when a troll tries to make his/hers/its point with a vague,
biased assumption:
I mean, it's not that slow - wait, I guess it's slower, because I...
I think so! Yeah! It's slow! At least it feels like it...
It's all about choosing the right tool. If you think Python doesn't
suit your
On May 24, 1:56 am, cm_gui [EMAIL PROTECTED] wrote:
i'm not trying to 'troll' here.
Maybe you're not trying, but you're succeeding.
If you want to criticize be constructive about it, otherwise get out.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 23 May 2008 14:00:33 -0700 (PDT),
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 23 mai, 10:42, inhahe [EMAIL PROTECTED] wrote:
Bruno Desthuilliers [EMAIL PROTECTED] wrote in
messagenews:[EMAIL PROTECTED]
Brad a écrit :
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't
have complained
that python is slow. python websites are slow.
if python is such a good programming/scripting language, why can't they
build a faster interpreter/compiler engine? and beat php and zend.
to the python team, rebuild your interpreter!
torontolife.com is slow.
okay, maybe
if python is such a good programming/scripting language, why can't they
build a faster interpreter/compiler engine? and beat php and zend.
to the python team, rebuild your interpreter!
while this is just a boring troll.. it does bring me to a more
interesting point... it would be cool if the
Brad a écrit :
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between.
I find it suitable for lots of stuff. I use C++ when performance really
matters tho... right tool for the job. Learn a good interpreted language
(Pyhton) and a good compiled
On May 23, 3:50 am, Bruno Desthuilliers bruno.
[EMAIL PROTECTED] wrote:
Brad a écrit :
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between.
I find it suitable for lots of stuff. I use C++ when performance really
matters tho... right
Bruno Desthuilliers [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
Brad a écrit :
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between. I
find it suitable for lots of stuff. I use C++ when performance really
matters tho... right
On 23 май, 02:20, Brad [EMAIL PROTECTED] wrote:
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between.
I find it suitable for lots of stuff. I use C++ when performance really
matters tho... right tool for the job. Learn a good interpreted
inhahe [EMAIL PROTECTED] writes:
planets are spherical (all implementations of Python are not natively
compiled (and you said for whatever definition)), and b) It's a far cry to
imagine a planet coming into being that's not spherical (a language as
dynamic as Python, or most other scripting
Carl Banks a écrit :
(snip technically pedantic correction)
You know, even though you're technically correct, I'd like to see you
abandon this little crusade. At this point it's more noisy than
helpful.
(snip)
Mmm... You're probably right. I tend to be way too pedantic sometimes.
OTHO, there
On 2008-05-23, RPM1 [EMAIL PROTECTED] wrote:
Larry Bates wrote:
If your Python program is slow, you have almost assuredly
approached it with a wrong method or algorithm.
I agree for most applications. There are however times where
Python just isn't fast enough, and that's usually when
On May 23, 2008, at May 23:10:11 AM, Grant Edwards wrote:
On 2008-05-23, RPM1 [EMAIL PROTECTED] wrote:
Larry Bates wrote:
If your Python program is slow, you have almost assuredly
approached it with a wrong method or algorithm.
I agree for most applications. There are however times where
Troll much?
--
http://mail.python.org/mailman/listinfo/python-list
2008/5/22 cm_gui [EMAIL PROTECTED]:
Python is slow.Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so much faster
than
Bonsoir !
Perso, je pense que des précisions comme celles de Bruno sont très
utiles, car elles évitent les dérives, et l'apparition de langages
bâtards, et impurs (pythonesquement parlant).
Non aux Pythons OGM !!!
Toutefois, iles est dommage que je comprenne pas l'anglais, et donc pas
Paul Rubin http://[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
inhahe [EMAIL PROTECTED] writes:
planets are spherical (all implementations of Python are not natively
compiled (and you said for whatever definition)), and b) It's a far cry
to
imagine a planet coming into being
On 23 mai, 10:42, inhahe [EMAIL PROTECTED] wrote:
Bruno Desthuilliers [EMAIL PROTECTED] wrote in
messagenews:[EMAIL PROTECTED]
Brad a écrit :
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between. I
find it suitable for lots of stuff. I
Python is slow.Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so much faster
than Python.
Okay, they probably use caching
On May 22, 11:14 am, cm_gui [EMAIL PROTECTED] wrote:
Python is slow. Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so
On Thu, May 22, 2008 at 12:14 PM, cm_gui [EMAIL PROTECTED] wrote:
Python is slow.Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written
I don't get what the issue is between sites that use Python and being slow,
if there is one, because there's a website online that shows the results of
a dozen or so benchmarks when comparing any two languages. Python beats PHP
in almost all the benchmarks. (it also beats almost all the other
On May 22, 9:14 am, cm_gui [EMAIL PROTECTED] wrote:
Python is slow. Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so
cm_gui [EMAIL PROTECTED] writes:
Python is slow.Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so much faster
than
On 22 mai, 18:14, cm_gui [EMAIL PROTECTED] wrote:
Python is slow.
Oh, a troll...
Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written
cm_gui wrote:
Python is slow.
It ain't C++, but it ain't a punch card either... somewhere in between.
I find it suitable for lots of stuff. I use C++ when performance really
matters tho... right tool for the job. Learn a good interpreted language
(Pyhton) and a good compiled language (C
cm_gui wrote:
Python is slow.Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so much faster
than Python.
Okay
On May 22, 6:14 pm, cm_gui [EMAIL PROTECTED] wrote:
I've yet to see a web application written in Python which is really
fast.
I bet you have a slow dial-up connection.
--
http://mail.python.org/mailman/listinfo/python-list
On May 22, 12:14 pm, cm_gui [EMAIL PROTECTED] wrote:
Python is slow.Almost all of the web applications written in
Python are slow. Zope/Plone is slow, sloow, so very slooow. Even
Google Apps is not faster. Neither is Youtube.
Facebook and Wikipedia (Mediawiki), written in PHP, are so
101 - 200 of 310 matches
Mail list logo
