"Delaney, Timothy C (Timothy)" <tdelaney@avaya.com> wrote:
> > From: Guido van Rossum [mailto:guido@python.org]
> >
> > OTOH there's something to say for fewer errors, not more;
> > e.g. sometimes I wish AttributeError and TypeError were unified,
> > because AttributeError usually means that an object isn't of the
> > expected type.
>
> Hmm ... I was going to ask if there was any reason not to make
> AttributeError a subclass of TypeError, but that would mean that code
> like:
>
> try:
> ...
> except TypeError:
> ...
>
> would also catch all AttributeErrors.
>
> Maybe we should have a __future__ directive and phase it in starting
> in 2.4?
>
> I wouldn't suggest making AttributeError and TypeError be synonyms
> though ... I think it is useful to distinguish the situations.
>
> I can't think of any case in *my* code where I would want to
> distinguish between a TypeError and an AttributeError - usually I end
> up having:
>
> try:
> ...
> except (TypeError, AttributeError):
> ...
More hmmm...
Just grepped over my source tree (1293 .py files, ~ 300000 lines):
- 45 occurrences of `except AttributeError` with no mention of
`TypeError`
- 16 occurrences of `except TypeError` with no mention of
`AttributeError`
- 3 occurrences of `except (AttributeError, TypeError)`
Works well enough for me.
Deriving both AttributeError and TypeError from a common base would
make sense to me. Merging them wouldn't.
PS: As that was my first post here, a short introduction. I'm a
consultant using Python since early 1998. Since then the
precentage of C/C++ use in my daily work steadily shrank.
Nowadays, using C normally means generating C code from Python.
-- =
Christian Tanzer tanzer@swing.co.=
at
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4