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.
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