One Python 2.1 idea

[Hartmann Schaffer]

In article <926ici$vi9$1 at nnrp1.deja.com>,  <rturpin at my-deja.com> wrote:
> ...
>responsibilities. Application programmers should use the
>abstractions that best solve their problem, functionally,
>assuming that these are implemented well. Language
>implementors should strive to make sure that the
>implementation for an abstraction performs well in all
>the ways it is used. This route provides significant gains
>in productivity. But it only works if BOTH groups take up
>their mantle.

unfortunately, that simply doesn't work in practice.  programmer tend
to develop a style that is dictated by the implementation they are
using.  if a particularly abstraction performs lousy in the
implementation i'm using and my users are screaming that they are
falling asleep while waiting for a particular result, telling them
that it might get better with the next release of the compiler won't
cut it.  if i expect something like that to happen, i won't wait for
the complaints to come in, but write the code so that they won't,
i.e. avoid the abstraction

> ...
>I think this approach is misguided. A listBuffer, as
>far as I can tell, is functionally identical to a
>sequence. We've cluttered the language with another
>abstraction, whose only purpose is to help the compiler
>decide an implementation. Now, everyone learning Python
>has to learn about listBuffers, in order to read your
>code. This same mistake has been made already with
>xrange(). Given enough time, we'll have to teach
>programmers about a dozen different things that all
>behave like Python sequences. Blech!
>
>In my mind, the ideal is very different. The Python
>implementation should have a dozen or more ways of
>implementing sequences, depending on how they are
>constructed, what kinds of objects are put into them,
>the contexts in which they are indexed, whether they
>are used for iteration, etc. The vast majority of the
>time, these things can be determined at compile time.
>There shouldn't be a different language abstraction
>for sequences that are not stored. xrange() is an
>abomination. The compiler should simply use this
>implementation when it fits.
>
>ONLY ONE SEQUENCE ABSTRACTION SHOULD BE EXPOSED TO THE
>APPLICATION PROGRAMMER. It would be a mistake -- a BIG
>mistake -- to continue the process of cluttering up
>the language with new abstractions, merely to give
>implementation directive to the compiler. I vote we

noble thought, but i see at least two objections here:
   
1. the compiler can only find the best way to implement a general
   abstraction iff it can see all uses of a particular instance.  in a
   language that has seperate modules that come together at execution
   time this often is not the case

2. the programmer should be able to communicate to the compiler all
   the relevant information about the particular instance of an
   abstraction he uses that s/he is aware of.  whether you use extra
   language features or annotations is irrelevant, and i would argue
   that for all practical purposes the annotations are as much part of
   the language as some special construct, only that it uses a
   different syntax.  if the implementation improves, the compiler is
   as much free to map different source constructs into identical
   internal constructs, as it is free to ignore annotations

> ...

hs