[PATCH] A compromise on case

[Grakka]

Although easily readable error messages are something definitely needed,
imho, I am really not waiting for that feature as I am for using a
kick-butt python debugger..

=-=-=-=-=-=-=-

24 hours in a day...24 beers in a case...coincidence?

Nick Mathewson wrote:
> 
> On 24 May 2000 14:11:41 +0200,
>        Martin von Loewis <loewis at informatik.hu-berlin.de> wrote:
> >nickm at mit.edu (Nick Mathewson) writes:
> >
> >> Thanks!  I'm going to hold off on this for a few more iterations;
> >> the patch I wrote is not very clean or well-tested, and it
> >> definitely doesn't belong in the main dist.
> >
> >Why not? It is helpful to all users, beginners or not.
> 
> Mainly, because it isn't clean or well-tested. :)
> 
>  [...]
> >> I mainly intended it as a demonstration of how I think errors should
> >> work.  If people agree with me, then I'll clean up the code.
> >
> >I have two suggestions: In order to avoid hard-coding the error
> >message, I recommend to put this code into NameError and
> >AttributeError, like this:
>  [...]
> >Then, you create a name error with NameError(not_found, do_you_mean)
> >
> >Next, if you want to delay computation of the alternative name, you
> >could also define
>  [...]
> >Then, an attribute error would be raised as AttributeError(name,obj).
> >That holds a reference to the object, but that should be ok, since it
> >does not introduce a cyclic reference.
> 
> Great ideas; I'm incorporating them right now.  I'm also applying your
> second idea to NameError; instead of a (name,obj) pair, NameError wants
> a (name, frame) pair.
> 
> >Given an intelligent implemenentation of find_nearest_match, it could
> >also detect other kinds of typos.
> 
> Stop-it-you-two!-It's-a-high-level-programming-language-and-a
>    -great-spell-checker-too!-ly Y'rs
> 
> --
> Nick Mathewson     <nickm at mit.edu>     http://www.mit.edu/~nickm/
> --
> http://www.python.org/mailman/listinfo/python-list