# Error Messages for methods

**URL:** <https://discuss.python.org/t/error-messages-for-methods/83362>\
**Category:** Ideas\
**Tags:** error-handling\
**Created:** [March 6, 2025, 1:50pm UTC](https://discuss.python.org/t/error-messages-for-methods/83362 "2025-03-06T13:50:29Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![donBarbos](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/donbarbos/32/25833_2.png) [@donBarbos](https://discuss.python.org/u/donBarbos)\
**Post date:** [March 6, 2025, 1:50pm UTC](https://discuss.python.org/t/error-messages-for-methods/83362/1 "2025-03-06T13:50:29Z")

</div>

In issue #130821 there was a proposal to unify error messages and @storchaka recommended opening a discuss here, so I’ll explain:  
We decided to add a type before the method name so the messages will be updated anyway. And it would be convenient to make one template for such errors at the same time. There are several variants:  
`{TYPE}. __method__ should return ..., (...)` (current state in parentheses)  
`{TYPE}. __method__ should return ..., not ...` (or must return)

Here are some examples of such error messages:

```python
__bool__ returned non-bool (type %T)
__index__ returned non-int (type %T)
__int__ returned non-int (type %T)
%.50s. __float__ returned non-float (type %.50s)
__buffer__ returned non-memoryview object
__annotate__ returned non-dict of type '%.100s'
__len__ () should return >= 0
__hash__ method should return an integer
__init__ () should return None, not '%.200s'
__sizeof__ () should return >= 0
__getnewargs_ex__ should return a tuple, not '%.200s'
__getnewargs_ex__ should return a tuple of length 2, not %zd
__length_hint__ () should return >= 0
__length_hint__ must be an integer, not %.100s
read() should return bytes
readall() should return bytes
decoder should return a string result, not '%.200s'
encoder should return a bytes object, not '%.200s'
iterator should return strings, not %.200s (the file should be opened in text mode)

```

---

<div class="post-metadata">

**Author:** ![barry-scott](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@barry-scott](https://discuss.python.org/u/barry-scott)\
**Post date:** [March 6, 2025, 2:16pm UTC](https://discuss.python.org/t/error-messages-for-methods/83362/2 "2025-03-06T14:16:20Z")

</div>

In RFC docs **should** means optional, **must** mean mandatory.

Changing the should’s to must’s could be considered at the same tine.

---

<div class="post-metadata">

**Author:** ![franklinvp](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/franklinvp/32/11142_2.png) [@franklinvp](https://discuss.python.org/u/franklinvp)\
**Post date:** [March 6, 2025, 2:34pm UTC](https://discuss.python.org/t/error-messages-for-methods/83362/3 "2025-03-06T14:34:47Z")

</div>

> [@donBarbos](#):
>
> (current state in parentheses)

It is nice to see what was given, but sometimes there might not be a way to represent the state, or doing so can unnecessarily cause more errors.

For example, in those that `should return >=0`, it is clear that if the error is emitted, then what was given doesn’t satisfy that condition. If the return value were `-2**9999999`, it might not be nice nor useful to try to represent it.

---

<div class="post-metadata">

**Author:** ![srittau](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/srittau/32/237_2.png) [@srittau](https://discuss.python.org/u/srittau)\
**Post date:** [March 6, 2025, 4:44pm UTC](https://discuss.python.org/t/error-messages-for-methods/83362/5 "2025-03-06T16:44:32Z")

</div>

This is the referenced GitHub issue: [Inconsistent error messages when returning the wrong type for the type-conversion magic methods · Issue #130821 · python/cpython · GitHub](https://github.com/python/cpython/issues/130821)

---

<div class="post-metadata">

**Author:** ![donBarbos](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/donbarbos/32/25833_2.png) [@donBarbos](https://discuss.python.org/u/donBarbos)\
**Post date:** [April 30, 2025, 12:03am UTC](https://discuss.python.org/t/error-messages-for-methods/83362/6 "2025-04-30T00:03:38Z")

</div>

Thanks everyone for the comments, I suggest the final version of message:

```python
{TYPE}. __method__ () must return ..., not ...

```

I think the `, not ...` part can be optional and situation dependent, but it’s fine for type errors.

---

<div class="post-metadata">

**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\
**Post date:** [April 30, 2025, 6:40pm UTC](https://discuss.python.org/t/error-messages-for-methods/83362/7 "2025-04-30T18:40:07Z")

</div>

Something is bothering me. Saying `{TYPE}. __int__ () must return int` is a great understatement, because _every_ ` __int__ ()` method must return int. But it is useful also to inform what ` __int__ ()` returns a wrong type. It may not be important, but is there a way to say this in English more naturally while still keeping the message concise?

---

<div class="post-metadata">

**Author:** ![uranusjr](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/uranusjr/32/103_2.png) [@uranusjr](https://discuss.python.org/u/uranusjr)\
**Post date:** [June 15, 2025, 2:47am UTC](https://discuss.python.org/t/error-messages-for-methods/83362/8 "2025-06-15T02:47:37Z")

</div>

Personally I feel `{TYPE}. __int__ () must return int` is fine. Yes, all ` __init__ ()` must return int, but the user only needs to care about `{TYPE}. __int__ ()` specifically right now.
