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

2007-03-22 Thread 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. Howev

Re: Best Free and Open Source Python IDE

2007-02-08 Thread Enrico &#x27;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

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

2006-09-24 Thread 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 env

Re: Python and STL efficiency

2006-08-24 Thread 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

Re: Python and STL efficiency

2006-08-24 Thread 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

Re: Python and STL efficiency

2006-08-23 Thread 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://

Re: Python and STL efficiency

2006-08-23 Thread 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

Re: Python and STL efficiency

2006-08-23 Thread 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. Ir

Re: Python and STL efficiency

2006-08-23 Thread 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 |

Re: Python and STL efficiency

2006-08-23 Thread 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!

Re: Python and STL efficiency

2006-08-22 Thread 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 f

Re: Python and STL efficiency

2006-08-22 Thread 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 P

Re: Python and STL efficiency

2006-08-22 Thread 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: h

Re: Python and STL efficiency

2006-08-22 Thread 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:

Re: Python and STL efficiency

2006-08-22 Thread 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 the

Re: Python and STL efficiency

2006-08-22 Thread 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

Re: Python and STL efficiency

2006-08-22 Thread 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++ o

Re: Python and STL efficiency

2006-08-22 Thread 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

Re: Python and STL efficiency

2006-08-22 Thread 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 fil

Re: Python and STL efficiency

2006-08-22 Thread 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

Re: Python and STL efficiency

2006-08-22 Thread 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 53

Re: Simulation Programming Skills and Python

2006-03-07 Thread 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

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

2006-03-03 Thread 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/p

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

2006-03-03 Thread 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 M

Re: sockets, where can I find documentation?

2006-03-03 Thread 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/mailma

Re: Threading - will threads run in parallel?

2006-03-01 Thread 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: Path completion in 'raw-input'?

2006-03-01 Thread 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: Th

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

2006-03-01 Thread 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 cri

Re: Is Python a Zen language?

2006-02-28 Thread 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