New Python 3.0 string formatting - really necessary?

[bearophileHUGS at lycos.com]

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