python improvements (Was: Re: New Language)

[Steven D. Arnold]

At 02:41 PM 5/12/2000 +0000, pohanl at my-deja.com wrote:
>Ok, here are some ideas for the new language...

[...]

>This new language would have components with no constraints on values
>passed to it.

First let me say that I love Python.  It's a dazzlingly good 
language.  When I started programming perl, I marvelled that there was a 
language that went so far out of its way to make the programmer's life easy 
and enjoyable; I still owe perl a debt of gratitude for being the first in 
that category, at least the first I was exposed to.  Perl wasn't a 
theoretical purist's language; it was a language intended to help the 
programmer, period.

However, putting sentimentality aside, python is both theoretically 
brilliant and extremely helpful to the programmer, as much or more than 
perl in every regard I care about.  From the work I have done already in 
python, I can say without the slightest hesitation that manipulating 
complex data structures, using and writing complex class hierarchies, etc, 
is far easier in python than perl.  Python is definitely more pleasant to 
read, more pleasant to write, syntactically far clearer....etc.  I would 
far rather maintain a complex python project than a complex perl project.

Having said that, I feel python can use some improvements.  (So could any 
world-class Olympic athlete.)  I will allow that this point of view may be 
a misperception on my part due to an incomplete understanding of the 
langauge; and I invite anyone with more knowledge than I to show me how the 
following goals can be cleanly attained in python.


1. I'd like an equivalent to perl's "use strict" pragma.  It's annoying to 
have to be so paranoid about making a typo in a variable name.  I'd like 
the compiler to be able to catch those errors for me.

2. I'd like the ability to specify that a certain parameter or variable is 
of a given type.  This can help prevent a class of runtime errors (though 
of course we could use introspection and try/except blocks, but that adds 
code that, with a type declaration, could be avoided).  Furthermore, I 
would find it very useful when I'm trying to understand a method or 
function.  Often I see a parameter and I have no idea what type the 
parameter is supposed to be.  What class do I look in to find the method 
this var is supposed to be using?  I have to guess.  If I had a 
sophisticated class browser for python, this task would be easier, but it 
could still involve guessing.

One addendum to the above: If I declare a variable to be of a given class, 
I should also be able to pass any subclass.

3. I'd like to allow for the formal declaration of protocols a la 
Objective-C.  A protocol is a set of method calls that an object can claim 
to support or not.  Protocols can be defined to support a variety of useful 
behaviors.  For example, drag 'n' drop might be implemented as a protocol, 
where you accept a given data stream as part of a protocol::drop 
method.  This also prompts an extension to suggestion (2) above: I should 
be able to declare that a given parameter requires an object that conforms 
to a given protocol.  Then, instead of being a specific type, the object is 
guaranteed to support the protocol (actually, its class has registered 
support for the protocol and implements the required methods and perhaps 
the optional methods).


Don't misunderstand the intent of these suggestions: I do not want to make 
python more like C++ in the sense of imposing a bunch of annoying 
strictures.  I merely want to give the programmer the option of being more 
restrictive, especially if it helps ferret out bugs early.  Let's give 
python programmers the option of using some of the features of C++ that 
find bugs early in the development process, even if we don't require 
programmers to use those facilities.

Nuff said.  Python kicks ass.  I'm a convert!


--
Steven D. Arnold          Que quiero sera           stevena at permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard."    -- John F. Kennedy