[PATCH] A compromise on case

[Jeff Senn]

nickm at mit.edu (Nick Mathewson) writes:
...
> names.  I decided the best way to do this was to patch the code that
> raises NameError and AttrError.
> 
> My rationale was this: Guido has said that he's considering
> case-insensitivity because beginners often run into problems.  ***My
> hypothesis is that their problems aren't due to the language, but due
> to the unhelpful error messages it gives.*** After all, who could
...
> So I tried to make a quick-and-dirty patch the Python interpreter to
> do something more reasonable.  Here's a sample interaction:
...
>     >>> print MAP(square, [1,2,3])
>     NameError: No such name as 'MAP'.  Perhaps you meant 'map'?

Merits of the patch aside (I like the idea!), it still doesn't get to
the core of *why* Guido suspects there are benefits to making the
language case-insensitive.

Just consider how to handle the more complex case of code like:

  CountOfLumberJacksAvailable = 12
  if something.or.other():
     CountOfLumberjacksAvailable = CountOfLumberJacksAvailable + 1
  print CountOfLumberJacksAvailable

Code, which you will notice, generates no "errors"...

Guido's assertion (which I believe) is that we humans are not used to
reading case as being significant to the meaning of a word -- in
addition our ability to even perceive the case of a word is pretty
poor.  I'm sure that there are studies in the cog-sci reading-
comprehension area that support this result and demonstrate that memory
for case is pretty pathetic.

Guido is developing a language product for enabling people to use
computers -- not training people to (rearrange their perceptual
systems to) think the way a computer does.

-- 
-Jas