One Python 2.1 idea

[rturpin at my-deja.com]

Let me frame, up front, where I think we disagree. We
both love Python for its level of abstraction, its
flexibility, its portability, and its ability to serve
as glue. The issue is NOT Python vs. something else. It
is about how Python should evolve AT THIS POINT in its
lifecycle. My view is that Python, from a language
viewpoint, is quite mature. There are not a lot of big
abstractions yet-to-be implemented. Or if there are, I
have not seen them discussed. Most of the enhancements
now proposed are small and incremental. Python has
reached the point where the greatest gains come from
improving its underlying infrastructure: more speed,
running on more platforms, supporting larger-scale
programming. This is GOOD. It is a sign of success.

Stackless Python is a small but exciting step in the
direction of improving infrastructure. I wish, instead
of being a side project, this kind of work were now
the core focus. And the coming feature enhancements?
Well .. changing the scope rules for lambda is pretty
limited in application. Creating a short-cut for
range() in "for" statements is a step backwards, since
it is yet another special case in the syntax that
people must learn to understand the code. DON'T DO IT.
At the language level, the Pythonic philosophy of
explicit and readable is correct. (Such short-cuts are
NOT required to optimize performance. The compiler, not
the programmer, should recognize and optimize common
functions, in contexts such as for statements!)

In article <924bjt0e3n at news1.newsguy.com>,
  "Alex Martelli" <aleaxit at yahoo.com> wrote:
> So, the list comprehension in this case is SLOWER
> by over 10% than the map-and-lambda. ..

The degree of my disappointment depends on the commitment
to improve the implementation. The implementation of a
more abstract construct often is slower -- initially --
than the hand-coded alternative using lower level
constructs. There were many early DBMSs where coding a
join yielded a speed improvement over the SQL. BUT. This
situation should quickly reverse. In the DBMS world, it
did, and because of that, SQL won. It won, not just in
the sense that it is used, but in the sense that using
SQL for these purposes is now preferred to hand-coding
the abstractions it implements. For 10% penalty, I'll use
list comprehensions, with the expectation that in a year
or two, I'll gain an X% bonus. (And if we don't? What
good does it do to have list comprehensions if programmers
routinely use loops instead, because they know it will
get them an easy 10% performance boost? The goal is not
just to provide nice abstractions, but to seem them used!)

One BIG benefit to abstractions like JOIN and list
comprehension is that performance improves without the
application programmers doing anything. The next release
of the programming environment makes everything run
faster. Or so one hopes. This is well understood in the
DBMS world. We teach beginning SQL programmers to use
the constructs, even if they think they can beat the
current implementation. That's what we also ought to
teach Python programmers, right?

> Actually, for all-out speed in a higher-level language, ..

Why restrict ourselves to higher-level languages? For all
out speed with portability, we could program in C.

> I prefer Python because I do NOT prize speed in a
> higher-level language above other factors -- great
> practicality at "playing well with others", clarity,
> cleanness of syntax, great productivity.

I would explicitly list "working at a higher level of
abstraction." Many things improve productivity, some
of which Python lacks. There is a lot to be said for a
highly integrated programming environment, as one finds
in Delphi. But the tie to a specific GUI framework
limits portability. I am glad that Python made the
choice of simplicity and abstraction.

> If you do have another scale of values, Python may not
> be the best choice for you at this time; specifically,
> if for some reason the solutions MUST be single-language
> ones (you can't or won't use a lower-level, faster
> language for that 10% or so of your code that bottlenecks
> its speed).  I do not have any such constraint, so Python
> + some tiny amount of C++ at the right places .. is
> exactly right for my needs...

This introduces friction that undermines precisely Python's
greatest selling point: increase in productivity. The
problem is NOT just programming in C the parts of an
application that are bottlenecks, but first identifying the
bottlenecks. That's not too hard for those of us with
experience at it; more difficult for many. And keep in mind
that the solution may not be programming in C, but rewriting
in longer-winded Python, which thereby becomes less readable
and understandable, now undermining maintainability.

My bottom line is this: I don't think we should make people
choose either-or. Either take the level of abstraction
provided by Python (and solve performance problems after
the fact) OR use something else. Python CAN BE faster. There
is nothing in the language that forces list comprehensions
to run slower the simple lists. Living with this either-or
makes sense early in a technology's lifecycle, when the
abstractions are new and getting them out is more important
than getting them fast. But they're out. It is time to shift
the emphasis a bit, from features to infrastructure.

I might be persuaded otherwise if you would point out the
BIG feature enhancements that are just around the corner.
Right now, I don't see them. So what do I want next, more
than anything else? More speed. And availability on all
the palm platforms.

Russell



Sent via Deja.com
http://www.deja.com/