My wishlist for Python3K

[Huaiyu Zhu]

On Thu, 8 Jun 2000 22:00:32 +0200, Thomas Wouters <thomas at xs4all.net> wrote:
>
>> Would there be a problem with the ambiguity of "3./2" being parsed
>> as either
>>   '3.' '/' '2' == 1.5
>>   '3' './' '2' == whatever ./ does to scalar integers, probably
>>                   make it be regular division == 1
>>   ?
>
>I'm afraid I was a bit careless in the quoting. I am not implementing the
>'dot operators' for numerical computation, I'm only implementing augmented
>assignment (+=, >>= and friends.)  But for what it's worth, I think the 'dot
>operators' as using a dot are out -- there is no way the parser can
>distingish between float-creation, attribute-lookup and matrix-operations,
>and still remain as obvious as it is now. At least, I dont think so.  Using
>another character would be possible, of course ;)
>

Then could somebody else help to implement the dot operators?  It doesn't
matter whichever character is used in place of dot, although looking at my
keyboard I don't see any better candidates - may be due to the matlab effect.

The potential ambiguity can only come from digits, not letters:

Expression   Can be      Can't be     Better written
a./b         a ./ b       a. / b
2./3         2 ./ 3                   2 ./3
             2. / 3                   2.0/3
                          2. ./ 3     2.0./3

Here's what octave does
octave:1> a = [1, 2; 3, 4]
a =
  1  2
  3  4
octave:2> 3./a
ans =
  3.00000  1.50000
  1.00000  0.75000
octave:3> 3. /a
error: operator /: nonconformant arguments (op1 is 1x1, op2 is 2x2)

This is quite reasonable, which many people have lived with for years.  On
the other hand, due to the distinction between int and float in python, and
lack of matrix in core language, it might be better to let (2./a == 2. / a).
No exising code will be broken.  A greedy parser would handle this.

Huaiyu