Thank you everyone for the discussion, it has been, as always, most
educational. :)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/
On Thu, Nov 6, 2014 at 1:10 AM, Nick Coghlan wrote:
> Right. Especially in a ducktyping context, AttributeError and TypeError
> are often functionally equivalent - it usually isn't worthwhile adding code
> specifically to turn one into the other.
>
Yeah, these are so often interchangeable that I
On 6 Nov 2014 06:53, "Alexander Belopolsky"
wrote:
>
>
> On Wed, Nov 5, 2014 at 2:47 PM, R. David Murray
wrote:
>>
>> As I said on the issue, there is no reason I can see to add extra code
>> just to turn an AttributeError into a TypeError. The AttributeError
>> works just fine in letting you kn
On Wed, Nov 5, 2014 at 2:47 PM, R. David Murray
wrote:
> As I said on the issue, there is no reason I can see to add extra code
> just to turn an AttributeError into a TypeError. The AttributeError
> works just fine in letting you know your input type didn't work.
>
+1
Unlike ValueError or Loo
Ethan Furman wrote:
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?"
I don't think I've *ever* been bothered by getting an
AttributeError instead of a TypeError or vice versa.
Both indicate bugs in m
On Wed, 05 Nov 2014 11:13:37 -0800, Ethan Furman wrote:
> On 11/05/2014 10:56 AM, Raymond Hettinger wrote:
> > 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
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 l
On 11/05/2014 10:09 AM, MRAB wrote:
On 2014-11-05 16:33, Ethan Furman wrote:
Even worse (in my opinion) is the case of an empty Counter `and`ed with an
incompatible type:
--> c &= [1, 2, 3]
-->
No error is raised at all.
The final example, however, is odd. I think that one should be fixed.
> On Nov 5, 2014, at 8:33 AM, Ethan Furman wrote:
>
> I'm looking for real-world uses of collections.Counter, specifically to see
> if anyone has been surprised by, or had to spend extra-time debugging, issues
> with the in-place operators.
Please stop using the mailing lists as way to make a
On 2014-11-05 16:33, Ethan Furman wrote:
I'm looking for real-world uses of collections.Counter, specifically to see if
anyone has been surprised by, or had to
spend extra-time debugging, issues with the in-place operators.
If sufficient and/or compelling use-cases are uncovered, the behavior o
I'm looking for real-world uses of collections.Counter, specifically to see if anyone has been surprised by, or had to
spend extra-time debugging, issues with the in-place operators.
If sufficient and/or compelling use-cases are uncovered, the behavior of
Counter may be slightly modified.
Back
11 matches
Mail list logo
