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

[Steve Holden]

Paul Rubin wrote:
> 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.)
> 
Of course the tradition answer to this question is "reframe your
algorithm in multi-process form". My response to that tends to be "Isn't
that what computers are for?"

> 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.  
> 
Speed, of course, isn't everything. But it would be nice to accommodate
those problem classes where it *is* significant.

> 3) Data encapsulation, the subject of most of this thread.
> 
There's always more to do there, though I fell the thread started out
based on a misapprehension.

> 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.
> 
That part of Python 3'sw design is, of course, totally intentional. I
believe Guido is on record as saying that he hopes the uses for the
annotation feature can be concretized (is that a word) down the line
when good use cases have emerged. And I believe they will (as you
suggest to be desirable) always be optional - almost like a pragma in
other languages.

> 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.

I have to confess that I occasionally find some of your posts a bit
pedantic and obscurantist. Just the same I appreciate your continued
presence on the list, because no matter how unreasonable I feel what you
says to be, when I examine it I always find your opinions well expressed
and well thought-out.

Sometimes I just want to shout "be quiet, Python is just fine the way it
is", but alas your objections are usually too sensible to be dismissed
in that way. In the long term I feel it has to be good for Python that
it has such conscientious critics.

Ultimately it may well be that some other project than CPython
represents the way forward for the language. I don't think that day has
arrived yet, but that doesn't mean we should exclude the possibility out
of hand.

regards
 Steve

-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/