New Python 3.0 string formatting - really necessary?

[MRAB]

bearophileHUGS at lycos.com wrote:
> 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.
> 
I would've hoped that Python 4000 would address the internals (JIT) just 
as Python 3000 addressed the externals.