R. David Murray added the comment:
On Mon, 03 Nov 2014 10:53:09 +0000, Ethan Furman <rep...@bugs.python.org> wrote:
>
> Ethan Furman added the comment:
>
> > I don't want to change the kind of exception being raised (an API change
> > from
> > AttributeError to TypeError) without a really good reason.
>
> Subclasses cannot work with the current implementation.
I don't understand this statement.
> > Also, I prefer the current AttributeError with its clear indication that an
> > items()
> > method is needed for duck-typing. These kind of error messages are very
> > helpful
> > when you're trying to figure-out how to duck-type on-purpose
>
> That's what the docs are for.
That's not the way it works in real life. You implement something, it
doesn't work, and if the solution isn't obvious from the error message
*then* you look at the docs or google. But if the error message says
"you can't do this", then like as not you don't even look at the docs.
> > (for example, {}.update(1) and {}.update([[]]) both provide the information
> > about
> > what you would need to do to get update() to work).
>
> update is not a binary operation, so has more leeway in how it handles
> problems.
As Raymond pointed out, the augmented assignment operator is a
*shortcut* for update.
> > The current duck-typeable behavior was an intended part of the design and
> > is no
> > different from a number of other methods that update in-place.
>
> The only problem with the design is that it does not play well with others.
> For duck-typeable just do a check on 'other' to see if it has an .items()
> method, and return NotImplemented if it does not. Oh, and check that 'self'
> is Counter, and also return NotImplemented if that fails.
No, that doesn't support duck typing. Duck typing is not putting
arbitrary restrictions on what objects you accept, but only essential
restrictions. And as noted above, if you return NotImplemented, then
you get an error message that essentially says "this is impossible"
instead of "this is what didn't work".
> Here's proof of subclass trouble -- the idea is to make an immutable Counter:
Your subclass doesn't override __iadd__ or any of the other mutation
methods. Why would you expect it to be immutable if it doesn't?
> For subclassing to work, the fix is:
>
> if not hasattr(other, 'items') or type(self) is not Counter:
> return NotImplemented
I've never seen a type check like that in a Python class, and I hope
I never do. *That* breaks subclassing.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22766>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
