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.
so "an operation" in your original question is limited to operations that
may have resulted in an AttributeError or a TypeError depending on the
type, and the change means that they will now be more consistent?
doesn't sound too bad to me.
> > 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...
>
> Not clear what that means...
the second sentence should have been:
on the other hand, if this change DOESN'T affect any code in the
standard library, chances are that it'll only break a few of the ~1000
uses I found in my company's code repository...
> 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.
have you made ANY changes to the library this far?
</F>
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