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
Surprising behaviour when passing list to os.path.join. #67968
Comments
I just accidentally passed a list (instead of unpacking it) to os.path.join. I was surprised when it just returned the list unmodified: >>> os.path.join([1, 2, 3])
[1, 2, 3] Looking at the source, it simply returns the first argument (path = a; ...; return path) when the '*p' part is empty. I think a "genericpath._check_arg_types('join', a)" or similiar should be added at the top, or it should ensure the "*p" part is not empty (as the docstring says "two or more pathname components"). |
Using Python 3.4.3 on Windows 7 Home Premium 64 bit, Service Pack 1: >>> import os
>>> os.path.join([1, 2, 3])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Program Files\Python 3.4\lib\ntpath.py", line 108, in join
result_drive, result_path = splitdrive(path)
File "C:\Program Files\Python 3.4\lib\ntpath.py", line 161, in splitdrive
normp = p.replace(_get_altsep(p), sep)
AttributeError: 'list' object has no attribute 'replace' I think this atribute error should be handled differently, like informing the programmer that you cannot use a list in the join method. |
Python's philosophy is one of duck typing, which means that in general we just let the functions fail with whatever error they produce when the in put datatype is wrong. The error message in this case is fairly straightforward: you passed a list and it says that that data type doesn't work. The linux case is a bit more problematic in that it *doesn't* produce an error for invalid input. The problem there is that we can't raise an error if there's only one argument for backward compatibility reasons: there almost certainly exists code that depends on single argument path returning the argument. In theory there shouldn't be code that depends on that single argument being an incorrect data type, but it would still only be something we'd consider changing in a feature release. I'm not sure it is worth fixing, frankly, but I've attached a patch we could consider applying to 3.5. (aside: the isinstance check in _get_sep looks like a bug report waiting to happen...it will do the wrong thing if passed a bytearray or memoryview...) There may be others who will advocate for a stricter type check or a try/except with a "better" error message...I'd be OK with the better error message as long as it doesn't break the duck typing rule. |
Error message for ntpath is improved in 3.5. >>> import ntpath
>>> ntpath.join([1, 2, 3])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/serhiy/py/cpython/Lib/ntpath.py", line 111, in join
genericpath._check_arg_types('join', path, *paths)
File "/home/serhiy/py/cpython/Lib/genericpath.py", line 143, in _check_arg_types
(funcname, s.__class__.__name__)) from None
TypeError: join() argument must be str or bytes, not 'list' I'm not sure that the case of single argument in posixpath.join needs a fix. First, any argument checks have a cost. Second, currently os.path works with string-like objects if they implement enough string methods. But David's proposition looks enough harmless (but this line should be added inside the try block). Do you want to add tests David? If apply it to posixpath, it should by applied to ntpath too, because currently ntpath.join doesn't raise an exceptions for empty list.
It is documented that os.path only works with strings and bytes objects. It also can work with str-like objects if lucky. |
No, I'm not going to write tests...my goal is to commit other people's patches, and I haven't even found time for that lately. And like you, I'm not convinced the fix is needed. There is one argument I can think of in favor, though: currently code that doesn't raise an error on posix will raise an error on Windows, and there is some portability value in making this consistent. (Side note: the fact that join works with things that look enough like strings is important, because I'm sure that there are pathlib-like libraries out there that pretend to be strings so that they can be used in things like path.join.) |
Here is extended patch, with tests. |
Serhiy, I don't see a new patch added - did you forget to attach it or am I missing something? :) |
Oh, sorry, I forget to attach it. |
New changeset 84af71e8c051 by Serhiy Storchaka in branch 'default': |
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: