suggestion for Python

[Alex Martelli]

François Miville-Dechêne wrote:

> I find your language very nice, it is actually more than three quarters
> of what I had been dreaming for years a programming language should be.
> But I mourn the passing of APL, another interpreted language.  I like

Having worked a LOT with both APL and APL2 around 1977-1986, I don't
really mourn them at all (except when I'm in my cups, sometimes, but
then I'm mostly mourning the fact that 20 years ago I was younger:-).


> One suggestion I would propose would be to make common operators
> distributive by enclosing them in square brackets.  For instance:
> [1, 3, 5, 7] [*] [1, 2, 1, 3] would be equivalent to
> [[1, 3, 5, 7][i] * [1, 2, 1, 3][i] for i in range(3)]
> In APL the common operators were implicitly distributive over vectors,
> but it is not possible for Python due to the more evident concatenation
> meaning of + and *.  The map function does the job for a user
> defined-function, as would do in this instance something like
> map(multiply, [1, 3, 5, 7], [1, 2, 1, 3]), but it is cumbersome to
> redefine simple operations.

import operator
map(operator.mul, [1,3,5,7], [1,2,1,3])

and you're done.  Or, to taste,

[ a*b for a, b in zip([1,3,5,7], [1,2,1,3]) ]


> One problem with Python is the necessity to define very short functions
> to enable operators to be the object of function of functions such as

Yes, we do lack a _good_ syntax for "codeblock literals" -- about a
month ago we were discussing possibilities quite actively here.

> map.  Another problem is that common operators cannot be easily
> redifined onto larger mathematical objects one might conceive and could
> be defined by the means of classes.  This could be solved by setting
> that such functions named as add, mult, div, defined as two-parameter
> functions, would automatically correspond to the dyadic +, *, /, etc.

Standard library module operator has those.  But I'm not sure what you
mean by "redefined onto larger mathematical objects" -- you can get
operator overloading on any type by defining __add__ __mul__ etc.


> And conversely, any name of a two-parameter function, let it be
> hypothenuse, would signify when enclosed in parentheses the
> corresponding dyadic operators.
> 
> so that 3(hypothenuse)4 would be 5

Yep, Haskell has something like that, except that instead of
yet another overloading for parentheses (which have too many
already!-) it uses `...` which in Python are an unfortunate and
useless duplciate for repr(...).  However to make sense you need
to be able to define priority and associativity and that gets hairy.


> This would give Python all the advantages of late APL and much more, for
> APL could process only regular data structures such as matrices whereas

APL2 could have arrays with each row a different length, which helped.

> Python is so good with data more to be encountered in real life such as
> ill-formatted texts to be divided in chapters, sections and subsections
> in order to fit in a certain software, just to name one intance, by the
> means of the use of reg exps and tree-processing.
> 
> Thanks for your attention.  The sole objection to the development I
> propose for Python would be a certain loss of readability for persons
> not acquainted with the language, but reg exps are not that readable
> neither and yet what would we do without them?

They're in a separate standard library module -- the criteria are laxer.
Getting into core Python demands passing MUCH stricter tests on all scores.


Alex