Re: Python and STL efficiency

[Mc Osten]

Jeremy Sanders <[EMAIL PROTECTED]> wrote:

> It must be the debugging, the compiler or a poor STL implementation. With
> gcc 4 it runs instantly on my computer (using -O2), even with 10x the
> number of values.

$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5363)

I adapted original poster's code and made a function that did not create
strings each time. The NoisyString is a class we can use to actually
track copying.

In fact Python here is faster. Suppose it has a really optimized set
class...


Here some results (I know that the fpoint optimizations are useless...
it's is my "prebuilt" full optimization macro :) ):




$ g++ -O3 -pipe -O2 -march=pentium-m -msse3 -fomit-frame-pointer
-mfpmath=sse  -o set_impl set_impl.cpp 
$ ./set_impl 
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 5.8
Elapsed 1.71

$ g++ -Os -pipe -O2 -march=pentium-m -msse3 -fomit-frame-pointer
-mfpmath=sse  -o set_impl set_impl.cpp 
$ ./set_impl 

What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 5.8
Elapsed 1.71

$ g++ -O3 -o set_impl set_impl.cpp 
$ ./set_impl 
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 0.47
Elapsed 0.18

$ g++ -o set_impl set_impl.cpp 
$ ./set_impl 
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 0.63
Elapsed 0.33

$ python -O set_impl.py 
so long...
What do you know
fool
chicken crosses road
so long...
What do you know
fool
chicken crosses road
Elapsed: 1.37 seconds
Elapsed: 3.81 seconds



--- PYTHON CODE -
#python

global size 
size = 100

def f():
a = []
for i in range(size):
a.append('What do you know')
a.append('so long...')
a.append('chicken crosses road')
a.append('fool')
b = set(a)
for s in b:
print s

def slow_f():
a = []
for i in range(size):
a.append('%s' % 'What do you know')
a.append('%s' % 'so long...')
a.append('%s' % 'chicken crosses road')
a.append('%s' % 'fool')
b = set(a)
for s in b:
print s

import time
from time import clock

f_start = clock()
f()
f_end   = clock()

slow_f_start = clock()
slow_f()
slow_f_end   = clock()

print "Elapsed: %f seconds" % (f_end - f_start)
print "Elapsed: %f seconds" % (slow_f_end - slow_f_start)

--


- CPP CODE -
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
using namespace std;


#define SIZE 100

class NoisyString : public std::string {
  public:
  NoisyString(const string& cp) 
  : string(cp) 
  {
  cout << "Fuck I got copied!" << endl;
  }
  
  NoisyString(const char* s ) : string(s) {

  }
  
  
  
};


void f(){
  vector a;
for (long int i=0; i b(a.begin(), a.end());
copy(b.begin(), b.end(), ostream_iterator(cout, "\n"));
}

void fast_f(){
  vector a;
  string s1  =  "What do you know?"   ;
  string s2  =  "so long..."  ;
  string s3  =  "chicken crosses road";
  string s4  =  "fool";
for (long int i=0; i b(a.begin(), a.end());
copy(b.begin(), b.end(), ostream_iterator(cout, "\n"));
}


int main(){
  clock_t f_start, 
  f_end,
  faster_f_start, 
  faster_f_end,
  fast_f_start,
  fast_f_end;
 
  f_start = clock();
  f();
  f_end   = clock();
  
  fast_f_start = clock();
  fast_f();
  fast_f_end   = clock();
  

  cout << "Elapsed " << (f_end - f_start) / double(CLOCKS_PER_SEC) <<
endl;
  cout << "Elapsed " << (fast_f_end - fast_f_start) /
double(CLOCKS_PER_SEC) << endl;
  
}

---




-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:

> I'm curious though, if on the OP's machine the slowed-down Python
> version is still faster than the C++ version.

I tested both on my machine (my other post in the thread)

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Fredrik Lundh <[EMAIL PROTECTED]> wrote:

> Python's memory allocator is also quite fast, compared to most generic
> allocators...

In fact also in the two "slow" versions Python outperforms C++.
I didn't notice it in the first place.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:


> But your C++ program outputs times in seconds, right? So all
> compilations except for the first two give results in less than a
> second, right? (meaning the optimizations of your standard-compilation
> give worst results than -O3?)

Yes. It's in seconds but the benchmark that are one order of magnitudo
less than the others have of a different "size" (10 instead of
100).  That is cut and paste from my terminal... I think it's a
mess. I do it all again from scratch.

> BTW, I don't quite understand your gcc optimizations for the first 2
> compiles anyways: two -O options with different values. Doesn't that
> mean the 2nd -O takes preference, and the compilation is at -O2 instead
> of -O3?
> Why both -O3 and -O2 at the command-line?

I forgot I put -O2 in my $FAST_FLAGS. I don't know what I was thinking
about.

This the correct version

$ g++ -Os -pipe -march=pentium-m -msse3 -fomit-frame-pointer
-mfpmath=sse  -o set_impl set_impl.cpp 

$ ./set_impl 
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 6.3
Elapsed 2.1

$ g++ -O2 -pipe -march=pentium-m -msse3 -fomit-frame-pointer
-mfpmath=sse  -o set_impl set_impl.cpp 
$ ./set_impl 
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 5.8
Elapsed 1.7

$ g++ -O3 -pipe -march=pentium-m -msse3 -fomit-frame-pointer
-mfpmath=sse  -o set_impl set_impl.cpp 
$ ./set_impl  
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 5.79
Elapsed 1.72

$ g++ -pipe -march=pentium-m -msse3 -fomit-frame-pointer -mfpmath=sse
-o set_impl set_impl.cpp 
$ ./set_impl
What do you know?
chicken crosses road
fool
so long...
What do you know?
chicken crosses road
fool
so long...
Elapsed 7.12
Elapsed 2.98

$ python -O set_impl.py 
so long...
What do you know
fool
chicken crosses road
so long...
What do you know
fool
chicken crosses road
Elapsed: 1.37 seconds
Elapsed: 3.80 seconds

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:

> Oh boy; yes indeed the slow python is faster than the fast C++
> version... Must be something really awful happening in the STL
> implementation that comes with GCC 3.4!

And the Python version does the very same number of iterations than the
C++ one? I suppose they are looping on arrays of different sizes, just
like my "first version".

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:

> NB: Your code now tests for address-equality. Does it also still test
> for string-equality? It looks to me that it does, but it's not quite
> clear to me.

It does it.

set b(a.begin(), a.end());
set c; // well ordered set (b is ordered by address)
for (set::iterator it=b.begin(); it!=b.end(); it++)
c.insert(**it);
copy(c.begin(), c.end(), ostream_iterator(cout, "\n"));

When we populate the first set, we get rid of all strings with same
object id/address (it test equality of pointers). Then we populate
another set (and the default equality test is on strings).

However, I would have written the code using a proper compare function
rather than using two sets. In this particular case the number of
elements of the first set is negligible in respect of the initial vector
size, thus copying it again does not take a lot of time.
But such code is optimized for the problem itself: in the real world I
suppose we would have passed set a proper comparison function that
checks address and then string equality.


-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:

> My conclusion from that is, that the vector<> or set<> implementations
> of GCC are far superior to those of VC++ 6, but that memory allocation
> for GCC 3.4.5 (MinGW version) is far worse than that of MSCRT / VC++ 6.
> (And Python still smokes them both).

It would be interesting to test it with VC 8 (2005). I have it in my
Parallels vm, but it looks like something is wrong. The very same code
takes almost a minute, I suppose there is something wrong with it
(Python is almost as fast as the python 2.4 on MacOS).



-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:

> And the results of IronPython (1.0rc2) are just in as well:

I can't test this one.

>
> And for Python 2.5:
> [EMAIL PROTECTED] ~/My Documents/Python
> $ /cygdrive/c/Python25/python.exe SpeedTest.py
> Begin Test
> Number of unique string objects: 4
> so long...
> What do you know
> fool
> chicken crosses road
> Number of unique string objects: 40
> so long...
> What do you know
> fool
> chicken crosses road
> Fast - Elapsed: 0.440619 seconds
> Slow - Elapsed: 1.095341 seconds


What the heck... you have a Cray, haven't you?
$ /opt/misc/bin/python2.5 -O set_impl.py 
so long...
What do you know
fool
chicken crosses road
so long...
What do you know
fool
chicken crosses road
Elapsed: 1.30 seconds
Elapsed: 1.29 seconds

Yes... good optimizer work. The 'slow' code here is faster than the fast
one.


$ python -O set_impl.py 
so long...
What do you know
fool
chicken crosses road
so long...
What do you know
fool
chicken crosses road
Elapsed: 1.36 seconds
Elapsed: 3.80 seconds

> (Next step would be to create a VB version and a Java version of the
> same program, oh and perhaps to try a version that would work with
> Jython... perhaps somehow w/o the 'set')

Ok. I can do the Java version. If I find a RealBasic Set class I can do
it. However, I don't remember anything about VB6, and have done nothing
with .Net.
But I don't think it is that interesting. Java strings are immutable
too: I expect it to outperform Python (unless Java Set class sucks). And
I don't see the point of taking in VB.
A good BASIC implentation is comparable with Pascal or C++ speedwise.
(At least this results from Great Language Shootout and Free Basic). 

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Ray <[EMAIL PROTECTED]> wrote:

> I'm using VC++ Express, I didn't care to tweak the optimizations, I
> merely chose the "Release" configuration for the executable. It's
> blazing fast, taking only 30+ ms each run.

Of course it is faster. We are looping 100 times, you just 1.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Ray <[EMAIL PROTECTED]> wrote:

> Not really, see my test, in my other post in the same thread. I'm using
> VC++ Express 2005. If we're comparing with Python 2.5 I think it's just
> fair that for C++ we're using the latest as well.

In your test, you are looping 1 times, we looped 100.
In Python tests with 1 elements, it was about 10 ms.

Moreover, we tried various Python and C++ configurations. Most of the
tests are done with Python 2.4, not 2.5.
And I used gcc4, that is to say the latest on my platform.
 
> Same here, although that said Python's implementation of those data
> structure must already be as optimal as mortals can do it. 

I think this is the rationale behind it.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

<[EMAIL PROTECTED]> wrote:

> That's to say,
> python is still much faster?

Yes it is. But of course you can't sat that "Python is faster than C++".
We found that the code to do this, written in the most natural way, is a
lot faster in Python. However, if you optimze the code, C++ gets almost
as fast.

In other benchmarks C++ outperforms Python and is 10 or 100 times
faster.


> Maybe someone can post this to the c++ maillist and they will tell how
> to accelerate it.

There are enough C++ experts here to do it. The point is another.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Ray <[EMAIL PROTECTED]> wrote:

> Certainly--I was not comparing 100 against 1. Referring to the
> OP's statement: "However, while the python code gave the result almost
> instantly, the C++ code took several seconds to run!" 30ms sounds like
> a definite improvement over several seconds!

Of course. I suppose there's something broken in OP's C++ setup (in fact
the version I compiled with VCPP 2005 also takes a lot of seconds...
something like 20-30 seconds, but of course this makes me think I
haven't understood how it is supposed to work, since my gcc gives
results comparable to yours).

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

GHUM <[EMAIL PROTECTED]> wrote:

> Proofed @ EuroPython
> 2006 in CERN, near the LHC Beta, in the same room many Nobel laurates
> gave their presentations before.

Have you some link? I suppose it's kind of a joke they did or something
like that...

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Ray <[EMAIL PROTECTED]> wrote:

> Yeah, my guess would be either he used the Debug configuration or he
> actually created a Managed executable instead of a pure Win32
> application. Sigh, now I can't wait to get home and try it out :)

Can be. But I suppose a Managed should not get *that* slow. 
IronPython on Tim's machine is still faster than C++ (even though not as
fast as CPython).

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Tim N. van der Leeuw <[EMAIL PROTECTED]> wrote:

> I have to admit to a stupid mistake, for which I feel quite ashamed - I
> got the loop-size wrong in the Python code. So all Python results
> posted by me were off by a factor of 10 :-(
> I feel quite bad about that!

Well, this makes *my* results quite surprising.
I checked it threetimes. I loop 100 times in both Python and C++,
and Python here is faster.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Ray <[EMAIL PROTECTED]> wrote:

> Great to know that my model of how the world works is still correct!
> (at least in relation to Python and C++!) :)

So please explain my results. I loop the same number of times.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Neil Cerutti <[EMAIL PROTECTED]> wrote:

> Those of you experiencing a temporary obsession with this topic
> are encouraged to study The Great Language Shootout, until the
> obsession goes away. ;)

I think that everybody knows GLS. However, when I have results different
from what I expected, I try to understand where I did the wrong
assumption.

However, a recent post kind of explains what the problem is.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python and STL efficiency

[Mc Osten]

Neil Cerutti <[EMAIL PROTECTED]> wrote:

> Those of you experiencing a temporary obsession with this topic
> are encouraged to study The Great Language Shootout, until the
> obsession goes away. ;)

I think that everybody knows GLS. However, when I have results different
from what I expected, I try to understand where I did the wrong
assumption.

But a recent post kind of explains what the problem is.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Running Python script from C++ code(.NET)

[Mc Osten]

volcano <[EMAIL PROTECTED]> wrote:

> A trivial question - I have a working Python script that I have to
> invoke from C++ code. No fancy stuff - just run the whole script with
> its parameters. No callbacks, no signalling - nada, just
> stupid,primitive, straightforward call.

 In a unix based environment I would use fork + exec*. IIRC in Windows
you should have a CreateProcess function call.




You could also try system, but it's generally considered insecure.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is Python a Zen language?

[Mc Osten]

On 26 Feb 2006 14:55:04 -0800, Andrea Griffini wrote:

> IMO another language that would be hard to classify is COBOL ... but
> for other reasons :-)

According to Dijkstra:

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence." 

That makes Cobol a Zen language (since it not only changes, but also
cripples the mind).

And BASIC too:
"It is practically impossible to teach good programming to students that
have had a prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration."

-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Is it better to use class variables or pass parameters?

[Mc Osten]

On 1 Mar 2006 11:32:02 -0800, Derek Basch wrote:

> This one has always bugged me. Is it better to just slap a "self" in
> front of any variable that will be used by more than one class method
> or should I pass around variable between the methods?

I think there is no clear "general" answer. A criterion could be that
instance variables should be those who define the state of the object, that
define its "meaning".

About the others to me it's a matter of taste.

-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Path completion in 'raw-input'?

[Mc Osten]

On Wed, 01 Mar 2006 10:00:43 -0800, Johannes Graumann wrote:

> There's also the rlcompleter module, but in the interest of better platform
> agnosis I'd like to stick with cmd ...

I would have suggested readline..

This works on Windows:


This about readline on MacOS:


[ you don't need if you use Python 2.4 from undefined.org
 ]



-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Threading - will threads run in parallel?

[Mc Osten]

On 28 Feb 2006 11:20:05 -0800, SolaFide wrote:

> (get() is a function which waits for a ping on a specific port, thus
> stopping the program for a while.)

It's a busy wait?

-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sockets, where can I find documentation?

[Mc Osten]

On Fri, 03 Mar 2006 11:41:05 GMT, John Pote wrote:

> Where can I get the various papers mentioned in the manual? And as I like 
> books sitting on the shelf can someone recommend a book on sockets.

Unix Network Programming by Stevens

-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how do you move to a new line in your text editor?

[Mc Osten]

On Thu, 02 Mar 2006 18:58:50 GMT, John Salerno wrote:

> I use UltraEdit right now, and it is possible to convert spaces and tabs 
> back and forth, but it's just an extra step.

I wouldn't definitely suggest UltraEdit to code Python.
Probably you should try scite. 

 I'm using TextMate (but it's MacOS only). When on Linux I use Emacs or vim
(depends on what I find on the machine). On Windows I prefer gvim to Emacs,
since I've not yet found a well integrated Emacs distribution (I said I
did't find it, not that it doesn't exist).


-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how do you move to a new line in your text editor?

[Mc Osten]

On Fri, 03 Mar 2006 16:48:11 GMT, John Salerno wrote:

> Why do you say that?

Because I tried it and it just lacks a lot of functionality you get with
TextMate or Emacs. It is quite stupid when indenting, just to name one.

-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simulation Programming Skills and Python

[Mc Osten]

On Mon, 06 Mar 2006 10:48:46 -0500, Richard Blackwood wrote:

> Two, is 
> Python a good language for simulation programming?

Civilization 4 is (partly) written in Python. I suppose they thought Python
was a good language for that. I said partly because as far as I know some
code is C++ for speed reasons.

-- 
USB Priests for only 10$
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: why brackets & commas in func calls can't be ommited? (maybe it couldbe PEP?)

[Enrico 'Mc Osten' Franchi]

<[EMAIL PROTECTED]> wrote:

> But I think in some situations Ruby allows to omit them, solving some
> of the "impossibile" problems shown in this thread. This makes Ruby a
> bit better than Python to create application-specific mini languages,
> that are quite useful in some situations.

Yes. However, Ruby parser has to resort to heuristic in many cases:



"When Ruby sees a name such as ``a'' in an expression, it needs to
determine if it is a local variable reference or a call to a method with
no parameters. To decide which is the case, Ruby uses a heuristic."

In fact it is something I don't really like about Ruby (even though I
find it useful in some cases).

This is a 'pathological example'

def a
  print "Function 'a' called\n"
  99
end


for i in 1..2
  if i == 2
print "a=", a, "\n"
  else
a = 1
print "a=", a, "\n"
  end
end


But I have to say that omitting brackets in a language such as Python or
Ruby can make the code very hardly readable. The interpreter isn't the
only one who has to resort to heuristic: everytime you read a name with
no parenthesis you may have to go back and see whether it is a bound
variable, a method (so you may have to check documentation for various
modules) or an 'invalid' variable you forgot to initialize.

In fact, when I'm reading code from a project I'm not familiar with, it
can be quite hard in the first place. 

In fact most Rubyists advice to use parentheses (unless you want to
achieve a DSL like effect, or in very simple cases like

puts s

)

The third problem I found out is related to blocks ({} and do have
different precedence order). They are only syntax errors, but I find
them annoying.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Best Free and Open Source Python IDE

[Enrico 'Mc Osten' Franchi]

Srikanth <[EMAIL PROTECTED]> wrote:

> All I need is a good IDE, I can't find something like Eclipse (JDT).
> Eclipse has a Python IDE plug-in but it's not that great.

Have you tried the 'full' plugin (you have to pay about 30 $ IIRC or
something like that)?

My favourite Python editor is TextMate a shareware (39 $) editor for the
MacOS. Before that I used gvim and then for a short time Emacs.
In my opinion an IDE is not necessary in Python. However, this may be
dependent from the way I work.

-- 
blog:  http://www.akropolix.net/rik0/blogs | Uccidete i filosofi,
site:  http://www.akropolix.net/rik0/  | tenetevi riso e
forum: http://www.akropolix.net/forum/ | bacchette per voi.
-- 
http://mail.python.org/mailman/listinfo/python-list