[Python-Dev] os.path.walk() lacks 'depth first' option

Christian Tanzer tanzer@swing.co.at
Tue, 13 May 2003 07:33:27 +0200


"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