Skip to content
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

Raise TypeError for non-paths in posixpath.relpath() #117584

Closed
nineteendo opened this issue Apr 6, 2024 · 4 comments
Closed

Raise TypeError for non-paths in posixpath.relpath() #117584

nineteendo opened this issue Apr 6, 2024 · 4 comments
Labels
3.13 new features, bugs and security fixes type-bug An unexpected behavior, bug, or error

Comments

@nineteendo
Copy link
Contributor

nineteendo commented Apr 6, 2024

Bug report

Bug description:

>>> import posixpath
>>> posixpath.relpath(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen posixpath>", line 509, in relpath
ValueError: no path specified

Expected: TypeError like npath.relpath().

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

Linked PRs

@nineteendo nineteendo added the type-bug An unexpected behavior, bug, or error label Apr 6, 2024
@erlend-aasland
Copy link
Contributor

erlend-aasland commented Apr 6, 2024

Changing the exception type is a backwards-incompatible change; some people will need to rewrite their exception handling to adapt to the new behaviour. Do the pros outweigh the cons?

@nineteendo
Copy link
Contributor Author

This is the same thing we did with non-iterables in ntpath.commonpath(): #117335
And it matches the error thrown by ntpath.relpath(), which better communicates what's wrong.

@erlend-aasland
Copy link
Contributor

I'll defer to Serhiy, who is particularly interested in such cases. cc. @serhiy-storchaka

@serhiy-storchaka serhiy-storchaka added the 3.13 new features, bugs and security fixes label Apr 7, 2024
@serhiy-storchaka
Copy link
Member

We usually do not bother with checking arguments more than necessary, especially in the Python code (which do not crash if you use wrong types or values). If the code happens to work outside the purposed area, well, someone can use it. If it fails with a weird error -- just do not do it. But in this case the change has zero performance cost, and TypeError is more suitable for None, 0 and [] than ValueError. It should be different from the error for '' and b''.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 new features, bugs and security fixes type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants