Does Python really follow its philosophy of "Readability counts"?

[Paul Rubin]

r <rt8396 at gmail.com> writes:
> Python and Ruby. Ruby only exists in this world because of the things
> it took from Python. Nobody would touch Ruby without it's Pythonisms.

I confess to not knowing much about Ruby.  It looks sort of Perl-ish
to me, and I always hear it is slower than Python, which is already
too slow.

> Python wins hands down, WHY? you ask. Well i could list a thousand
> reasons why but i will only cover a few.
> 
> 1.) read-ability
> 2.) ...
> I could keep going for days and days. Python is hands down the best
> thing that ever happened to the world of programming. Sure it could
> use a few improvements, nothing and nobody is perfect. But can any
> language stand toe to toe with Python? HELL NO!

Those things on your list are all nice, but I think Python has
considerable room for improvement in several areas:

1) Parallelism.  Commodity desktop computers now have 8 effective cpu
cores or maybe even 16 soon (Mac Pro, Intel Core i7) but Python still
has the evil GIL that forces all threads to run on one core.  Java,
Erlang, and Haskell (GHC) all beat Python in this area.  By the time
Python 4 comes out, we will probably all be using PC's with 32 or more
cores, so the current limitations will be intolerable.  Even today,
since no one doing anything serious uses single core machines any
more, the GIL is a huge pain in the neck which the multiprocessing
module helps only slightly.  (While we are at it, lightweight threads
like Erlang's or GHC's would be very useful.)

2) Native-code compilation.  Per the Alioth shootouts, Python is much
slower (even on single cores) than Java, Haskell, ML, or even Scheme.
PyPy is addressing this but it will be a while before it replaces
CPython.  

3) Data encapsulation, the subject of most of this thread.

4) Static analysis.  It would be great if there were a much more
powerful Pylint that could do ML-like type inference among other
things.  You could still program in a dynamic, heterogeneous style if
you wanted to, but Pylint would complain about it unless you supplied
some annotations to tell it where the dynamism was and how to separate
it from the rest of the program.  This is consistent with Python's
"consenting adults" principle: if consenting adults want to
participate in a BDSM scene, they should be allowed to.  There would
probably have to be some new language features to assist in writing
typefully.  Python 3.0 has some gestures in this direction but they
are not yet fully formed.

I believe that the PyPy project is developing the above areas in ways
CPython really could not.  While we are now committed to Python 3.0
being a CPython revision that makes some minor (and in my view
somewhat gratuitous) changes to the 2.x series, I hope that Python 4.0
will be based on PyPy and have more substantial differences.