Operator symbol for "nb_intdivide"

[Quinn Dunkan]

On Thu, 26 Jul 2001 18:08:34 GMT, Peter Dobcsanyi <petrus at pobox.com> wrote:
>But, I don't like the "//" operator symbol what we are supposed to use
>for implementing "a // b == floor(a/b)". Here are my reasons, in not any
>particular order reflecting (my subjectively assigned) importance:
>
>    - It is ugly, two characters.

Ugly is subjective... but it looks fine to me.  Two characters?  Well, 'and'
is three.  But if your concern is not "less readable" but "too much typing"
consider that they're the same two characters and don't need shift.  Consider
also that your priorities may be misplaced.

>    - Some languages use it for starting comments.

So?  Most don't.  Some use ';', many use '--', and some even use 'rem' or 'C'
at the beginning of a line.  I gather Visual Basic uses '.  Should python not
use single quotes?  I don't understand.

At least Eiffel uses // for integer division (and \\ for remainder... or is it
modulus?).

>    - "//" is hard to read, i.e. quickly clearly distinguish from "/"
>      the other division operator.

It looks pretty visually distinct to me.  But that's also subjective.

>    - When the transition period over (around 3.x or something) the
>      visual and typing characteristic of "//" can be source of error.

I don't quite understand this sentence :)

>At some stage in the future, the warnings will be turned off, everybody
>knows the new rules. But typing mistakes, oversights happen, so I can
>accidentally write "/" instead of "//" and vice versa:

That's the same situation as the current one: you have to know what kind of
division you want.  If you get it wrong, you get the wrong number.  No
warnings.  Only the current implementation uses the same operator for both
meanings, so you also have to know the types of the values on both sides (or
insure them with float() or int()).

>I would like to suggest to use a clearly distinguishable one-character
>symbol for the "nb_intdivide". PEP238 is to fix a "design fault". If we
>go for it despite of all the _temporary_ pain, we should not be shy,
>there is nothing wrong with doing it radically not just semantically but
>also visually. One of the nice virtue of the Python language is that it
>is readable, keep it this way.
>
>"nb_intdivide" and "nb_divide" are very different let's show this
>difference. Among the still free symbols ("?", "@", "$" I guess) I
>would suggest to use "$" for the integer division.

Ick.  At least '//' suggests division.  "x $ y" makes me think of some kind of
low-precedence function application or something.  No thanks.

I do like the idea of 'div' and 'mod', but I also appreciate the reluctance to
pile on the reserved words.  We already have 'yield', that should be enough
for a few years (although I would have preferred 'suspend').  I also like the
idea of ad-hoc `infix` operators, but that's already been mentioned :)