[Patches] From comp.lang.python: A compromise on case-sensitivity

[Nick Mathewson]

Guido van Rossum <guido@python.org> wrote:
 [...]
>This is a nice idea, although one could argue that you have it
>backwards: you're helping case-careless people to use a case-sensitive
>language, while what we really need now for forward compatibility is a
>warning when case-sensitive people use names in the same namespace
>that only differ by case.

Well, I won't try to carry the comp.lang.python flamewar to this list.
I agree with you that tools are the answer, though I prefer making
IDLE auto-correct case to changing the language itself. Still, it's
your decision. ;)

In the short and medium-term, however, this makes Python more usable.
I wonder whether an Alice-like research project would get the same
results about beginners and case-sensitivity if Python gave more
helpful error messages.

 [...]
>                                                     Recently, we
>discovered that there was a significant slowdown in class instance
>creation compared to 1.5.2, which (after considerable investigation)
>turned out to be due to code that made the AttributeError message a
>bit nicer.  What happened was that when a class has no __init__, an
>AttributeError was raised for that name, which was subsequently
>caught.  The code that raised the exception was changed to do a whole
>lot more work, which ended up being more work than the instance
>creation in the first place!

I see what you're saying, and I agree with it.  In fact, I'd bet there
is a lot of code written by people who don't know about 3-argument
getattr that looks like this:

         try:
            a = x.attr
         except AttributeError:
            a = None

As I noted, my patch adds a lot of overhead to raising AttributeError
and NameError.  This isn't good.

Martin von Loewis suggested an alternative that I'm implementing now:
instead of putting the find-a-close-name logic into ceval.c, I'm
change the __str__ methods of AttributeError and NameError.  This way,
we only do the expensive O(n) computation if the __str__ method of the
exception is actually called.

How does this sound to people?  One side advantage is that it makes
creation of AttributeError objects cheaper when they aren't printed,
and thereby actually improves the performance-critical case.

Of course, printed error messages remain expensive.

I should have a patch to send in later tonight.

--
Nick Mathewson     <nickm@alum.mit.edu>     http://www.mit.edu/~nickm/