Inconsistent error messages of `open` functions in `io` module implementations

[donBarbos]

Bug report

Bug description:

list where I found error message inconsistencies:

1. io.open()
   • _io impl raise: TypeError: open() missing required argument 'file' (pos 1)
   • _pyio impl raise: TypeError: open() missing 1 required positional argument: 'file'
2. io.open("file.txt", mode="")
   • _io impl raise: ValueError: Must have exactly one of create/read/write/append mode and at most one plus
   • _pyio impl raise: ValueError: must have exactly one of read/write/append mode
3. io.open("file.txt", mode=None)
   • _io impl raise: TypeError: open() argument 'mode' must be str, not None
   • _pyio impl raise: TypeError: invalid mode: None
4. io.open('file.txt', buffering="")
   • _io impl raise: TypeError: 'str' object cannot be interpreted as an integer
   • _pyio impl raise: TypeError: invalid buffering: ''
5. io.open('file.txt', encoding=0)
   • _io impl raise: TypeError: open() argument 'encoding' must be str or None, not int
   • _pyio impl raise: TypeError: invalid encoding: 0
6. io.open('file.txt', errors=0)
   • _io impl raise: TypeError: open() argument 'errors' must be str or None, not int
   • _pyio impl raise: TypeError: invalid errors: 0
7. io.open('file.txt', newline=0)
   • _io impl raise: TypeError: open() argument 'newline' must be str or None, not int
   • _pyio impl raise: TypeError: illegal newline type: <class 'int'>

I'm ready to take on

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

[Nathan-Bransby-NMT]

Is this to improve the readability of the error messages in _pyio to match those in _io?
If so could I please be assigned?

I'm trying to find something "small-ish" as my first contribution to the cpython repo.

[picnixz]

As we said on a similar issue concerning IO implementations, the Python implementation of IO is mainly used for testing and not by non-CPython implementations, so I'm not sure this one would be a "task" we'd be willing to do (cc @methane).

I'm trying to find something "small-ish" as my first contribution to the cpython repo.

You can try searching for the issues marked with the "easy" label. By the way, we don't assign issues to people; anyone is free to contribute but you can announce your intention of working on an issue so that other users know that someone is working on it.

[methane]

As a general rule, the content of Python error messages is not treated as part of the Python specification. This is evident, for example, from the fact that no deprecation period is required to improve error messages.

In other words, while it is desirable from a consistency standpoint to use the same error messages for Python and C implementations, it is not a bug to use different error messages.

So I don't disagree about this (+0), but I don't put much emphasis on being strictly consistent.

Python and C do not necessarily have the same optimal implementation in terms of performance and maintainability.

For example, many of the error messages about arguments are auto-generated in the C implementation; the Python implementation does not have the same kind of auto-generation.
Sometime, the C implementation may generate more helpful error messages. And sometime, the Python implementation may generate error messages that are more appropriate for the function.

Balance the two so that performance and maintainability are not greatly sacrificed for the sake of improving unimportant consistency.

[Nathan-Bransby-NMT]

Thank you both for the clarification 😊

[erlend-aasland]

Closing as per Inada-san's comment.