[Python-Dev] a slightly more coherent case

[Fred L. Drake, Jr.]

gvwilson@nevex.com writes:
 > 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]

  I don't recall any requirement that the host be able to deal with
Unicode specially (meaning "other than as binary data").  Perhaps I
missed that?

 > 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]

  I don't think the division sign itself is a problem.  Re-training
experianced programmers might be; I don't think there's any intention
of alienating that audience.

 > 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.

  A agree.

 > [3] Please note that I am not asking for a multiplication sign, a square
 >     root sign, or any of APL's mystic runes.

  As I indicated above, I don't think the specific runes are the
problem (outside of programmer alienation).  The *biggest* problem
(IMO) is that the runes are not on our keyboards.  This has nothing to
do with the appropriateness of the runes to the semantic meanings
bound to them in the language definition, this has to do convenience
for typing without any regard to cultured habits in the current
programmer population.


  -Fred

--
Fred L. Drake, Jr.	  <fdrake at acm.org>
Corporation for National Research Initiatives