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

[Russ P.]

On Jan 12, 3:34 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> r <rt8... 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.


Thanks for that nice appraisal. I agree completely.

I've suggested before here (as have others) that some sort of basic
data encapsulation would be nice, but many Python users don't seem to
want anything to do with it.

Also, static analysis would be very desirable for my purposes. I would
be more than happy to declare types if someone else would write an
advanced static analyser that could make use of the type information
and formally check the code for correctness. That has been done for
other languages such as Java and Ada, and it can be very useful for
safety-critical and mission-critical software. (I am currently
developing a research prototype of safety-critical software.)

I started looking at Scala a while back. It is has many nice features.
It seamlessly combines object orientation with advanced functional
programming. It is statically typed, but the types often do not need
to be explicitly declared. It is fully "compatible" with Java, but
(like Python) it is much less verbose and more elegant, typically
requiring less (in some cases, much less) than half the lines of code
for a given task.

But I am reluctant to use Scala for several reasons. For example, it
doesn't have "continue" and "break." The Scala folks claim they are
unnecessary, but they are sure handy sometimes. Maybe my style is bad,
but I use continue and break a lot, particularly continue. Getting by
without them could be hard. The other thing is that Scala has no
default arguments and no argument passing by keyword. Those are a
couple of my favorite Python features. So I'm basically screwed.