Discussion: new operators for numerical computation

Huaiyu Zhu hzhu at localhost.localdomain
Fri Jul 21 00:45:26 EDT 2000


On 20 Jul 2000 20:57:04 -0500, John Lull <lull at acm.org> wrote:
>At the dawn of the third millenium (by the common reckoning),
>hzhu at localhost.localdomain (Huaiyu Zhu) wrote (with possible
>deletions):
>
>> On Thu, 20 Jul 2000 11:49:01 -0400, Paul Magwene <paul.magwene at yale.edu> wrote:
>> >Konrad Hinsen wrote:
>
>> >A(+.*)B
>
>> There is one reason this will not be accepted eventually.  The parathesis
>> suggests the possibility of a calculas of operators within them, when, in
>> fact, operators are hardcoded in the C program.  John Lull had given a clear
>> explanation why this is so.
>
>I think your objection here is to the '+.*' bit, rather than the
>parentheses. Correct?  Do you have the same objection to the simple
>(*) ?

I do not have objection to this itself.  In fact I find this quite readable.
The problem is that after the previous long debate I got the feeling that
some people would reject anything that puts several symbols together just
because "it looks like perl" (which I do not believe is true).  I'm worried
this diversity might hurt the chance of getting anything accepted at all.

This is just a feeling.  Look it this way, it is one thing to argue that
there is a need for additional operators because the current ones are simply
not enough.  It is another thing to argue that there need to be a general
solution which leaves the door open for future extension.

In many situations making anything more general is likely to make it more
acceptable.  But in the case of operators there appears to be a general
hostility towards any extension, esp with many special characters.  This
could well change in the future, of course, if there is a very strong case.

Just my 2c.

Huaiyu



More information about the Python-list mailing list