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!"