New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error message of ord is not intuitive #71195
Comments
The error message of |
This not the only place where "string" means unicode string or bytes string. I don't think this is large issue. |
If you think it's OK, it's fine. Please close this thread. |
BTW, what do you think about the second TypeError in |
In any case it doesn't make much sense to change just one separate docstring. If you want to avoid misleading and support consistent wording, you should examine all occurrences of the word "string" in the documentation, docstrings, error messages and comments -- does it mean Unicode string, bytes-like object that supports the buffer protocol (including memoryview), bytes-like object that supports str-like interface (including bytes, bytearray, but excluding memoryview), either Unicode or bytes string? I tried to do this but abandoned the work on half-way. This is too large work.
It could be ValueError. But for compatibility it should stay TypeError. This is not wrong if we consider strings of size 1 as separate type. |
Ohh, you have tried to do that. It must be a large work. But on the other hand, if this is a too large work, why not solve this case by case? This work is too large to get someone work on it, even you, the most active developer in the community I see have abandoned. And then maybe improving the situation a little bit every time is the only solution.
This sounds weird. But I can understand the importance of compatibility. |
You are right, if it is too big a job to do it all at once, then we can fix them as we find them. Do you want to propose a patch? However, in this case I think there is arguably not a bug. It looks as though the intent is that ord only support strings (see the documentation). The fact that it supports bytes-like objects is redudant (ord(b'a') == b'a'[0]). I'd call it a bug that it supports bytes-like objects, but we probably kept (and should keep it) it to make it easier to port python2 code to python3. So, if any change were to be made here, it would probably be to change the error message if and only if the input is not in fact a string, and perhaps even recommend using the indexing syntax. On the gripping hand, I've never been a fan of the fact that indexing a byte string gets you an integer :) |
I also notice the document. I get surprised when I see the implementation also supports bytes while the doc says one unicode character. But then I tell myself that maybe unicode character also includes bytes? I am not sure about the English description. But giving your opinion that maybe the bytes supports are not intended now, I think leaving the error message untouched is quite OK. It describes what it is intended to do, same as the doc. Really glad to have your comments, Serhiy and David. |
All right, we'll close this then. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: