r: > I always thought of Python as an intuitive way to write C code.<
C is a very low level language, not far from assembly, and often it's not intuitive at all. C string formatting is short and a flexible enough, but it's out of place in a language as high level as Python3. The new syntax allows more flexibility, and it's better for most people that don't know C already, like newbies, etc. ------------------ walterbyrd: >It seems to me that 3.0 is changing a lot of non-problems. And it's going to be slower to boot.< They are non-problems for people that already know lot of Python (and some C). But for all the other people, especially newbies, it's better in most things. Most language designers (and generally people very used a certain language) become so accustomed to their language that they most of the times become like "blind" to the defects and warts of their language (I have said this four years ago too, when I have started learning Python, listing many problems in Python, and among them there were C string formatting too). So I think it was a feat for the Python developers to see many characteristics of the Python2.x as what they are: warts, bugs, etc, and fix them (and most of the times their newer designs are "the right thing" with just few exceptions, I have counted only 3 of them, and they are small). They have gained even more of my respect. Regarding the speed of Python3 programs, they will go faster because people will be forced to use things like lazy ranges, lazy map and filter, lazy keys and values, and the "key" of sort/sorted. All those things can be used in Python2.x too, but lot of people aren't expert enough (or they are just lazy) and don't use them, so the average Python3 program will probably be faster (and use less memory) thanks to them. Python3 programs will go slower because they use 2-byte long Unicode strings by default (it can be compiled for 4-byte Unicode too, and I think this has to become the default, eventually, because I think it will become silly to save few bytes for strings when you will have 8-16-32+ GB of RAM), and they use multi-precision integers only. Such strings and numbers allow to reduce some troubles, even "bugs", etc. At the moment Python3 isn't much optimized for speed, you can think of it an experimental release still. I/O and multiprecision integers will probably be speed up (and some form of transparent on-the-fly compression or smart representation can in most times halve the memory used by Py3 strings, putting the performance almost back to the Py2.x one. In computer science there are LOT of tricks that can be used if you have the brain and time to invent and implement them. You can see that for example in how Psyco manages internally string/list/tuple slices). Anyway, CPUs and computers are now much faster than the CPUs present when Python was created. And Python is first of all designed for the programmer and not for the CPU. So I think it's right to make Python3 become a little higher level language even if this slows it down a little. For the kind of programs Python is often used for, I think this is a Win. (Ruby programs are often slower than Python ones (because Ruby is a little higher level than Python) but it's very useful anyway). If Python will continue to develop in the following years (think about a Python4000) then I think it may become good to make it become even more slower, if this will help make it a little more higher level still. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list