Operator symbol for "nb_intdivide"

[Peter Dobcsanyi]

Dear warriors,

I have been following the intensive discussion about the proposed change
regarding PEP238. I don't claim I've read all post (only Guido and Tim
are capable to do that), but I've got the picture. Nevertheless, forgive
me if I am pummelling an old drum at the end.

Like for most of us, my first reaction was the panic: oh my god, how
much code it will break, too drastic change, too late etc. In my part,
there was some laziness involved too: damn! I have to re-learn something
and go back and fix my code, even if it is for good ... For me, the
latter part is not so bad as it looks first, since I always deployed my
code with the complete runtime environment, so I just could stick to
that.  Anyway, I was strongly in the opposition relentlessly gathering
the counter arguments.

But then, step by step, I got convinced that Guido was right and we
should bite the bullet. Why? here is an explanation (sorry Tim burning
you again):

[Tim Peters]
> I'm burned out on the repetition here.  It's not a question
> of being hard to teach.  It's largely that it's never sensible for
> 
> x = y / z                                    
> 
> buried in the middle of some routine to do truncating division if y and
> z happen to be ints but best-possible division if they happen not to be
> ints.  It's this damage to polymorphism that hurts people in real life,
> and we've had years of testimony about that on c.l.py (even in this
> incarnation of the debate, although it's hard to find unless you read
> every msg).
> 
> This isn't a question of teaching the rules, IT'S THAT THE SPECIFIC RULE
> HERE IS ESSENTIALLY BRAINDEAD IN A LANGUAGE WITHOUT STATIC TYPE
> DECLARATIONS. 
    <emphasis mine>

Turning my coat was also influenced by the fact the Guido with others
were trying very hard to accommodate the pain inflected. Finally, I
thought I could live with this gradual introduction of the beast and
Python would be better at the end, so be it. Also, I like the idea that
PEP238 opens the door to cleaning up the "numeric tower" in the future.

(Side note: Guido, I know that you must be sick of it for now, but it
might be worth to upgrade/extend PEP238.  Everything happened so
quickly, if one did not read the c.l.py for a few days and then noticing
the storm goes to see what caused it then there is a danger that you
will get the same opposition again and again just because the PEP
doesn't reflect all what we have learned during this debate.)

There is one detail I still feel uneasy about.  It is something to be
considered mainly for the time when we have finally got over the big
change and the dust settled down.  I agree that '/' should be the
operator which implements "(a/b) * b = a (more or less)".

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.

    - Some languages use it for starting comments.

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

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

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:

    def foo(x,y):
	# stuff here
	...
	z = x / y
	..
	# blah blah
	..

    i_wanted_int_div_but_mistyped_then_did_not_notice_for_a_while = foo

And there is no warning any more.

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.

Running_for_cover_ly y'rs,

    Peter