Here's a longer, and hopefully more coherent, argument for using the
divided-by sign in P3K:
1. If P3K source is allowed to be Unicode, then all Python programming
systems (custom-made or pre-existing) are going to have to be able
to handle more than just 1970s-vintage 7-bit ASCII. If that support
has to be there, it seems a shame not to make use of it in the language
itself where that would be helpful. [1,2]
2. As I understand it, support for (int,int)->float division is being
added to help people who think that arithmetic on computers ought to
behave like arithmetic did in grade 4. I have no data to support this,
but I expect that such people will understand the divided-by sign more
readily than a forward slash. [3]
3. I also expect, again without data, that '//' vs. '/' will lead to as
high a proportion of errors as '==' vs. '='. These errors may even
prove harder to track down, since the result is a slightly wrong answer
instead of a state change leading (often) to early loop termination or
something equally noticeable.
Greg
[1] I'm aware that there are encoding issues (the replies to my first post
mentioned at least two different ways for "my" divided-by sign to
display), but this is an issue that will have to be tackled in general
in order to support Unicode anyway.
[2] I'd be grateful if everyone posting objections along the lines of,
"But what about emacs/vi/some other favored bit of legacy technology?"
could also indicate whether they use lynx(1) as their web browser,
and/or are sure that 100% of the web pages they have built are
accessible to people who don't have bit-mapped graphics. I am *not*
trying to be inflammatory, I just think that if a technology is taken
for granted as part of one tool, then it is legitimate to ask that it
be taken for granted in another.
[3] Please note that I am not asking for a multiplication sign, a square
root sign, or any of APL's mystic runes.
