Slashdot Mirror
Python 2.3 Final Released
An anonymous reader writes "Nineteen months in the making, Python 2.3 has just been released. With a plethora of changes since version 2.2, this release is definately worth the upgrade. Be sure to read the Release Notes and the Highlights file for more information."
At the top of the list of new features they have sets. The first paragraph says that sets are implemented by hashtables. I wonder whether it is really meaningless from the "practical" point of view to implement sets with data structures like red-black trees or Fibonacci heaps. The advantage of the latter over hashtables is a solid bound on the worst case running times.
Out by an order of magnitude, and not getting closer any time soon. Last I checked, it's out by a factor of 100 or so for small operations (loops, etc)
Well, regular Python code can see some dramatic speedups, with just a little bit of extra work. Check out Psyco if you firmly believe that interpreted languages will never ever be as fast as C.
With sufficient cleverness, it may be possible to boost Python beyond the speed of the most highly optimized pre-compiled program.
Psyco and approaches like it do have drawbacks, but there is some very interesting work going on now with high-level languages.
This is a common saying when you talk with Python/Java programers. Plus, with something like wxPython, you can have a slick client application to boot.
Last time I saw unbiased performance comparisions, the difference between Python and Java wasn't really worth talking about.
Compiling alone wouldn't bridge the gap. Python already reduces interpreter overhead by using a pre-compiled byte-code. A large part of the problem is in dynamic typing: for example, when you say
a+b
in python, it's not equivalent to doing the same in C++. In python, you need to do a runtime type check and then decide what operation to perform, and only then can you add a and b. In C++, the dispatch can be performed compile-time.
What you really need to get a big speedup is some sort of mechanism that can eliminate a lot of this type checking (the other guy posted a link to an interesting approach to this problem)
But I've often been impressed with the ease of coding in such a language
It's a bit of a two-edged sort for the same reason -- the lack of type checking makes it easy to write code quickly, but it also makes it easy to code incorrectly.
What's wrong with it is that it's the syntax for dictionaries. Similar to hashes in Perl, it is a built-in type for Python. Anything wrapped in {} would probably be viewed as an attempt to make a dictionary by the parser.
I've discussed this with all my software engineering colleagues, and most of them have white space as their only hang up about the language. I thought this was pretty petty at first, given the other strengths of the language, but one person brought up an extremely good point. A co-worker at his company is blind. He said that having to deal with white space while coding was near impossible (maybe he uses a "pretty printer" or code beautifier after the fact? I don't know) Has anybody on
I do think it would be nice if there was a way to open and close a block (someone later down in the comments suggested preprocessor comments of and ) such that one could use either method. Perhaps there would even be a built in function of the interpreter to spit out the code one way or the other.
I must say I've gotten used to the whitespace over the past year. Using a decent editor makes life much easier in this respect. I would encourage anyone who hasn't tried out Python for this reason alone to give it a shot for a few weeks and see what you think.