A modest proposal (was: Comment on PEP-0238)

[phil hunt]

On 9 Jul 2001 16:51:04 GMT, Donn Cave <donn at u.washington.edu> wrote:
>Quoth Courageous <jkraska1 at san.rr.com>:
>...
>| [Snip: Guido's plan]
>|
>| This seems to me to be reasonable. While backward compatibility
>| is important in computer languages, the real problem occurs when
>| changes are abrupt. And in any case, we always have older versions
>| of the interpreter around.
>
>Sure.  For me, it looks like older versions is all we're going to
>have around.  Python is getting too complicated, has always been
>too slow (mainly startup cost), and now it's going to start breaking
>existing code in a serious way, for the sake of notions that are
>very debatable.

It seems to me that two forces are at work here.

One force, concerned about existing Python code, wants Python
to maintain as much backward compatibility as possible. This is
an entirely sensible concern, rooted in a pragmatism torward
software design. 

Another force, concerned about possible flaws in Python as it stands,
wants to improve the language. Thus we have new operators such as +=,
and other changes for the good. Thus also we have a PEP regarding 
integer division, which Guido thinks is a flaw in the current
version of Python. This attitude of wanting to make the most elegant
possible programming language is also entirely sensible, not
least because if Guido didn't think that way, Python wouldn't
exist and we'd all be using P**l or something like it.

So, how do we reconcile the two?

I suggest we continue to name the existing language "Python" and
the new developments by called under a different name ("SuperPython"
or "CP4A" possibly). That way, everyone gets what they want.

The new SuperPython would be free to experiment with radical new
ideas -- including changing the case-sensitivity, for example. And
the old, exisiting Python would be guaranteed to evolve in a way 
that doesn't break existing code, without a very very good reason.

Futhermore, SuperPython could compile to the same bytecode format
as Python. This would mean that existing Python libraries would
work with SuperPython.

-- 
## Philip Hunt ## philh at comuno.freeserve.co.uk ##