> guido wrote:
>
> > Q. If an operation that failed with an AttributeError now fails with a
> > TypeError (or the other way around), how important is that
> > incompatibility?
>
> what operations do you have in mind?
The specific example was this:
class C: pass
list(C())
The second line used to raise AttributeError: 'C' instance has no
attribute '__len__'; now it raises TypeError: iter() of non-sequence.
But I imagine there will be others, caused by the different (IMO
better) way of implementing getattr for most built-in types. (Note
that I'm hardly touching "classic" classes -- that's a post-2.2 job if
there ever was one.)
> cd Lib
> grep "except.*\(AttributeError\|TypeError\)" *.py */*.py */*/*.py
>
> gives me about 75 hits in the 2.0 standard library; looks like all but
> one would break if you changed *all* attribute errors to type errors,
> and vice versa...
>
> if this change doesn't affect any code in the standard library,
> changes are that it'll only break a few of the ~1000 uses I found
> in my company's code repository...
>
> </F>
Not clear what that means...
I tend to fix the test suite when it tests for too specific an error.
I don't think there are many cases in the library proper that are
sensitive to the kind of thing that might change.
--Guido van Rossum (home page: http://www.python.org/~guido/)
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