Guido>
>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).
>
After your explaination of the logic behind backquote, I agree that my
proposed change is probably undesirable ( for backquote, that is. )
But if not for "`object`", then maybe for "print thing" ?
>
>*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).
>
I prefer (all things being equal) regularity/orthogonality and logical
syntax/semantics in a language because there is less to have to remember.
( Of course I *know* all things are NEVER really equal! )
I can certainly live without these enhancements, or if I really need
them, implement them with my own classes on top of python. But I agree
with what you said about not wanting a dozen different ways of doing
the same thing ( as in perl, for example. I think it just makes it
more confusing to learn. ).
I can make my own classes to duplicate the builtin's: ( and make a
hierarchy: mySequence(), myMutableSeq() = mySequence, myList() =
myMutableSeq(), etc. and give them all .string() methods that
return a print representation. And either do "print thing.string()"
or make a write routine that checks the type or each arg and if
it is an object instance, uses that objects .string() method, else
uses the object itself.
But all this takes maintaining some conventions. I think that is
easier if the language encourages some conventions itself.
One such convention could be that (builtin) print does that checking:
if object instance, check to see it there is a method named
"_PrintRepresentation()" , and if there is, call that to get the
print string.
Note: this would not be necessary if "print" was user re-definable,
but it appears to be a statement, not a function. I don't know any
Modula-3, but I did do some Modula-2 programming at one time, and
I remember that some of the logic behind its design was the fact
that there were things in Pascal that were not implementable *IN*
Pascal for this very reason. ( I'm not convinced that the modula-2
solution was the right one - is that the reason for modula-3 ? )
( Of course in python, "write" is a file method and doesn't have
the pecularity of "print" )
Guido>
>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.
>
I can "live" with python just the way it is!
I find it much preferable to Perl in both its syntax, modularity and
interactiveness; easier and more high-level than C , and immensely
more powerful that csh/ksh/etc, although it is not concise enough
to COMPLETELY replace csh, but as I said before, you can't be all
things to all people.
It's only because it is SO good that I sometimes expect it to be
perfect! ( And sometimes I have a wrong idea of what perfect would be. )
These are just minor quibbles.
And if the answer DOES come down to just developing some coding
and method/class name conventions, then lets discuss THAT now and
develop some example code to ENCOURAGE those conventions.
- Steve