On 11/05/2014 10:56 AM, Raymond Hettinger wrote:
Please stop using the mailing lists as way to make an end-run around
discussions on the tracker.
http://bugs.python.org/issue22766
You said that without compelling, real-world use cases you don't like to make
changes.
The tracker has a very limited audience, while the mailing lists have a much greater chance of reaching the users who
may actually have the use-cases you would consider.
You call it an end-run, I call it research.
Also, as asked the question is a bit loaded. Effectively, it asks "has anyone
ever been surprised by an exception
raised by a duck-typed function or method"?
Actually, it's asking, "Most other duck-typed methods will still raise a TypeError, but these few don't. Has that ever
been a problem for you?"
The in-place operations on counters are duck-typed. They are intended (by
design) to work with ANY type that has an
items() method. The exception raised if doesn't have on is an AttributeError
saying that the operand needs to have an
items() method.
It would still be duck-typed with a `hasattr` call on the second operand checking for the necessary method, a TypeError
could just as easily state the problem is a missing `items()` method, and then those three [*] in-place methods would
raise the same error as the 20(?) other Counter methods under similar conditions.
Please let this one die. It seems to have become your pet project even after
I've made a decision and explained my
rationale.
You indicated you might make a change with sufficient real-world use-cases, so I'm trying to find some. If none show
up, I'll let the matter drop.
--
~Ethan~
[*] Amusingly enough, there are four overridden in-place methods: three raise an AttributeError, but one (&=) still
raises a TypeError.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
