Case-sensitivity: why -- or why not? (was Re: Damnation!)

[John W. Baxter]

In article <cppuqg4hsu.fsf_-_ at cj20424-a.reston1.va.home.com>, Guido van 
Rossum <guido at python.org> wrote:

Thoughts.

    1.  Various people want to write things like   s = S()
By habit, I never do that.  This is probably because of the several
years I spent writing in Pascal and Pascal-derived languages
(including NCRL [pronounced "swill" for reasons this thread
doesn't have room for] which may have been case sensitive).

Having said that, I sympathize with the people who do use
that style.


    2.  Pascal...I did use tools to fix the case of what I wrote.  But
I usually just wrote it the way I wanted it.  I never acted as
if _ were optional.  I had more problems with the 8-character
name significance in the implementations I used.


    3.  Braces...Roy Katz left out the C style I prefer:
       int func( ) {
           }
(I want to scan down from the start of the thing and find the
next thing, not the end of this thing.)


    4.  Off topic.  Integer division.  Perhaps my time spent
writing Forth code is what makes me very comfortable with
    1/2 == 0


    5.  URLs...the domain part is case-insensitive by design.  This
*probably* results from the domain name system having
been developed while we were still in the transition from
upper-case-only machines to 2 case machines.  It's very hard
to express   www.python.org   using a KSR-33 Teletype.

The path name part is either case sensitive, or not--depending
on the OS at the server end.  One insensitive example is
Personal Web Sharing on the Mac.  If it weren't for the fact
that I keep the server turned off 99.9% of the time, you could
reach my exciting home page on one of my Macs using any of
    http://coyote.scandaroon.com
    http://coyote.scandaroon.com/index.html
    http://coyote.scandaroon.com/INDEX.HTML
    (any other case variation you wish to try)

The actual file is named index.html

Despite the above, one is well advised to treat URLs as
case sensitive beyond the domain part.  [What is the
situation beyond the path part...I don't write them,
I click on them.]


    6.  HTML  If W3C have their way (doubtful, given past
behaviour of Microsoft and Netscape), HTML tags will
become case sensitive and will be lower case.


    7.  Randy Pausch via Guido (ie, I haven't read the original).
My guess--purely a guess--is that if Python 1.6 as it now does
things had been used, the number 1 problem would have been
that
     1.0 / 10
is not 0.1, displacing case sensitivity and 1/2 == 0 downwards to
numbers 2 and 3.  (Actually, it might have made 1/2 == 0 less
of a problem, since the students would likely already have
thought about the floating point issue.)


    8.  Francois:  "Why Scheme adopted case insensitivity is a mystery 
to me."
My guess is, as with domain names, timing, and the difficulty of
writing lower case on KSR-33 Teletypes and upper-case-only glass
teletypes.  LISP was originally simple:  upper case only thanks
to the IBM-026 card punches available at MIT.  [Thanks to the
overnight turnaround and the early interpreter's habit of
returning nothing at all useful if faced with a shortage of )s,
one could easily detect the LISP users:  they tended to walk
around with cards full of )))))))... in their shirt pockets, to be
slapped onto the end of submitted card decks:  one at least
got something back if there were too many )s.]


    9.  I haven't used IDLE...does it assume X in the Unix world?
If so, I will continue not having used IDLE at work...remote X 
over 56K frame is not something I want to investigate.
Therefore I won't have the help with casing that is being
suggested for IDLE.  [Of course, Python 3000 is in the future,
and my work situation might change before then.]


   --John (who got a lot of cards punched without waiting by
using the one-hole-at-a-time IBM-010 punch which for some
reason wasn't very popular)

-- 
John W. Baxter   Port Ludlow, WA USA  jwbnews at scandaroon.com