[PATCH] A compromise on case
Grakka
jflores at codeit.com
Thu May 25 18:19:02 EDT 2000
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
More information about the Python-list
mailing list