Re: WHY PYTHON?

I an a fan of Monty Python's Flying Circus, and I hate acronyms. Other than

that, there's nothing deep.



>(2) What role do you see python as fulfilling or in what direction do

>you anticipate its evolution ?

>( Perhaps it *can* be "all things to all people", but I wonder if there

>aren't some potential conflicts ahead between python as:

> an interactive environment & command interpreter.

> a command scripting language

> a general purpose scheme-like symbol processing language

> a GENERAL purpose high level language for everything else

> an object oriented language

> whatever else...

>I see python as potentially good in all these roles, but perhaps

>the needs and priorities differ. An interactive language needs

>conciseness, even if it creates syntactic irregularity. Regularizing

>built-in data types with user-objects, which would seem to be one

>desirable direction, might conflict with adding more built-in's

>( like vectors, for example ) for effeciency. )



I could go on for hours on this subject, but I'll keep it short this time :-)



The one thing that Python definitely does not want to be is a GENERAL purpose

programming language. Its lack of declarations and general laziness about

compile-time checking is definitely aimed at small-to-medium-sized programs.



As an interactive environment and command interpreter, it leaves a lot to wish

-- the bash history was really a hack to quickily get some kind of line

editing. I hope I can one day implement a better interactive environment in

Python -- there's a module "python.py" the demo/stdwin directory that shows a

little bit of how much can be done without changing the interpreter.



Object-oriented languages are a means, not a goal in themselves, so, yes,

Python is object-oriented (and more so than most other languages that claim

this adjective) but its goal in life is not to be OO.



I don't know what you mean by symbol-processing language. If you just mean

non-numerical computations, fine.



Looking in my crystal ball, I think that Python may develop stronger support

for medium-sized programs (e.g., some more compile-time error checking) but

won't lose a bit of its attractiveness for very short programs -- like scripts.



> One issue I will raise ( re: regularizing built-ins and objects ):

> I suggest that hooks to change the print representation of an object

> are desirable. Obviously, for user objects, one can write a '.print'

> method function for the object, and maintain the convention of

> consistently using that name ( or "._print" ). But it would be better

> if you could override "`" (backquote) for both user objects and

> built-in data types. COMMON-LISP has this capability: It comes in

> handy when you are dealing with large vectors/lists/tuples/etc. Instead

> of waiting for your terminal to print out a thousand number, you can

> change the print representation to be something like:

> "List of size=1024 : ( 0, 1, 2, ... 1021, 1022, 1023 )"

> Minimally, you should be able to change the string backquote returns.

> Maximally, you should be able to change the action when evaluating a

> symbol, i.e. , currently typing a symbol causes the equivalent to

> 'print `symbol` ' to occur. Instead of:

> >>> a = [ 1,2,3,4,5 ]

> >>> a

> [ 1, 2, 3, 4, 5 ]

> Typing 'a' could cause a plot of the values in a window.

> ( Probably this last is too much, and should be left to a user-level

> interpreted written on top of python. )

>

> In general, I think that regularization of built-in data types and

> user written objects is a good direction: allow operators like '+' to

> be defined for user-objects, and let built-ins be used as classes for

> inheritance. i.e. "class myList() = list: "



I don't think I agree that the level of modification of existing built-in

operations like you propose is a good thing.



For example, let's take backquotes. The problem is that not all uses of

backquote are used to write data to the terminal: as long as you don't use any

"weird" objects like files, the string output by `expr` is guaranteed to be a

valid Python expression that evaluates (using eval(), for instance) to an

object with the same value (approximately, in the case of floats).



*If*, and I say *if* there will ever be a mechanism whereby users can modify

built-in object types, I think it will be likely a way to add new methods to

built-in classes. A way to define standard operators like "+" for user-defined

types (classes) is also quite feasible -- I can imagine that a class can define

methods named _operator_plus, _operator_subscript, and so on (there must then

also be a way to indicate that a class implements a sequence, mapping or

numeric type).



Using built-in classes as base classes for user-defined classes poses several

problems, most of which lie in the realm of implementation. Several other OO

languages can live without this (C++, Modula-3), so I hope Python can as well.



Thank you for raising these issues,



--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>

"Is it a bird? No! Is it a plane? No! It's bicycle repair man!"

