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

[Mark Hammond]

Another far more controversial idea (and raised just for the sake of
brain-storming) would be for the attribute error to become a class with a
few optional fields - such as the object itself, and the attribute name.
It could then be done either by __repr__, or pushed down to the top-level
exception handler - eg, GUI environments make get even fancier - display
the candidates in a listbox, or you could go so far as to suggest and make
the code correction ;-)

The problem with doing it at __repr__ time is that generally you dont have
the object around any more - but you could possible walk the traceback and
extract it...  It does seem a more practical idea than mine :-)

Mark.

> -----Original Message-----
> From: patches-admin@python.org [mailto:patches-admin@python.org]On
> Behalf Of Nick Mathewson
> Sent: Friday, 26 May 2000 8:02 AM
> To: patches@python.org
> Subject: Re: [Patches] From comp.lang.python: A compromise on
> case-sensitivity
>
>
>
> 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/
>
>
> _______________________________________________
> Patches mailing list
> Patches@python.org
> http://www.python.org/mailman/listinfo/patches
>