[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

2010-02-17 Thread Paul Boddie
Paul Boddie p...@boddie.org.uk added the comment: I don't disagree that OverflowError describes what's happening, but the need to convert to an int in the first place is a detail of the machine - you'd have to know that this is a limitation of whatever internal protocol CPython implements -

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

2010-02-17 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: Interestingly, this (len returning something larger than ssize_t) has not been fixed in python3. On the other hand, I still think the new-style message is better. Yes, it is an implementation detail of CPython, but that is exactly the

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

2010-02-16 Thread Paul Boddie
New submission from Paul Boddie p...@boddie.org.uk: As noted here: http://www.selenic.com/pipermail/mercurial/2010-February/030068.html This is probably documented somewhere, and there may even be a good reason for the difference, but old-style classes raise TypeError when __len__ returns a

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

2010-02-16 Thread Paul Boddie
Paul Boddie p...@boddie.org.uk added the comment: I would have expected a more accurate error message for the new-style class. In the original message which brought this to my attention, the cause was not particularly obvious:

[issue7942] Inconsistent error types/messages for __len__ between old and new-style classes

2010-02-16 Thread R. David Murray
R. David Murray rdmur...@bitdance.com added the comment: In the example you give it seems to me that the message for the new style class is more accurate and useful than the message for the old style class. Looking at your mercurial example, it looks like the problem is the same (len