[Python-Dev] Re: linear algebra

[Greg Wilson]

> > Greg Wilson wrote:
> > 
> > .... Saying, "But you don't have to use these new operators if
> > you don't want to," is a red herring --- if I want to understand/modify
> > other people's code, I'll have to learn 'em (just as I've had to learn
> > most of Perl's syntax, one painful special case at a time, in order to use
> > the LDAP, XML, CGI, and imaging libraries).
> > 
> > So: I would like this (linear algebra, min/max, other notation) to happen,
> > but only if there's an extensible, scalable framework for user-defined
> > libraries to add operators to Python, in the same way that they can now
> > add new classes.  

> Paul Prescod wrote:
>
> I don't want to come to someone else's code and have to learn a bunch
> of operators that they invented, for the same reason that you don't
> want to learn all of Perl's built-in special cases.

Greg Wilson writes:
I strongly agree.  If there isn't a "new operator definition" mechanism
that maintains Python's simplicity, then I believe we should stick to
functions and methods, rather than introducing "just a few" new operators
for linear algebra (or regular expressions, or [your favorite topic goes
here]).

> Eric Raymond wrote:
>
> I agree that supporting user-defined syntax threatens to fragment the
> language. To avoid that, perhaps it would be best to leave what are in
> effect user-definable hooks in Python's lexical space.
>
> The design question becomes: what undefined binary tokens do we want
> to add the the language core?  With what precedence?  What is the
> compiler to assume about associativity?

This is an interesting alternative I hadn't thought of --- add operators,
with associated special methods and in-place assignment forms, but do not
provide a "standard" definition (i.e. leave all functionality open to the
user).

Thanks,
Greg