Well, personally, I don't see the advantage. I don't see the point of
having lots of different exception types that say "you made a
programming error" in different ways, and I severely doubt the
usefulness of being able to distinguish between those different
failure modes at run time. Others do. I doubt that one side is able to
convince the other side. So let's agree to disagree.
--Guido
On 5/8/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/8/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/8/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > > It'd certainly be nice to be able to tell the difference between
> > > the following two TypeErrors:
> > >
> > > >>> def s():
> > > ... raise TypeError()
> > > ...
> > > >>> 's'()
> > > Traceback (most recent call last):
> > > File "<interactive input>", line 1, in ?
> > > TypeError: 'str' object is not callable
> > > >>> s()
> > > Traceback (most recent call last):
> > > File "<interactive input>", line 1, in ?
> > > File "<interactive input>", line 2, in s
> > > TypeError
> >
> > You're kidding yourself. Consider these two:
> >
> > def s():
> > raise NotCallable("ha ha, fooled you!")
>
> This one does exactly what I would hope it to. The writer of the
> callable has indicated that this function is not to be called by
> raising NotCallableError. This would be especially appropriate in a
> subclass that wants to break substitutability and remove the __call__
> method. Sure, people could abuse it, but we're all supposed to be
> adults here, right?
>
> > or more likely any variant of this:
> >
> > def s():
> > 's'()
>
> Sorry if I came across as suggesting that adding NotCallableError
> would solve all the world's problems ;-) If you caught a
> NotCallableError, you would know that either the object you called was
> not callable, or it called some other object that was not callable and
> didn't trap the exception. That's a fair bit more informative than
> the current situation with TypeError, since a lot more things raise
> TypeErrors:
>
> >>> iter(1)
> Traceback (most recent call last):
> File "<interactive input>", line 1, in ?
> TypeError: iteration over non-sequence
> >>> 'abc'['1']
> Traceback (most recent call last):
> File "<interactive input>", line 1, in ?
> TypeError: string indices must be integers
> >>> str(1, 16)
> Traceback (most recent call last):
> File "<interactive input>", line 1, in ?
> TypeError: str() takes at most 1 argument (2 given)
> >>> 42 + '56'
> Traceback (most recent call last):
> File "<interactive input>", line 1, in ?
> TypeError: unsupported operand type(s) for +: 'int' and 'str'
>
> So if I catch a TypeError, it could be because the object I called was
> not callable, or it could be because when calling that object, any one
> of the above TypeErrors was raised.
>
> Still, like you say, NotCallableError's not a silver bullet.
>
> STeVe
> --
> Grammar am for people who can't think for myself.
> --- Bucky Katt, Get Fuzzy
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)