-
-
Notifications
You must be signed in to change notification settings - Fork 51
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
list using alternative to multipath #24
Comments
We could introduce the contract that path variants always return the first of the multipath. If users want multipath they would need to do: |
Alternatively, From what I can see, |
It also would mutate the type returned based on a boolean flag which I don't like at all 😬 |
In other words, the How come that there is a binary flag for this anyway? Wouldn't it make more sense to have two new api calls: |
Because for dirs the return type does not change 😬 because we don't return the paths as a list are but joined by os.pathsep. obviously we can't do that for pathlib. |
That is of course correct, but their output changes semantically, i.e. as a user I have to handle multipath output differently than singlepath output. It looks to me like all the arguments of a boolean-flag trap apply here as well. Nonetheless, #27 follows your suggestion to only return the first item in case |
Not really, UNIX site config values always return paths joined by os.pathsep... In simple case just happens to not matter, because joining an array of length 1 is always the same as the array element. |
We solved this for now by picking first for paths. str endpoints still work. |
i took note that the multipath variants will use a joined string instead of a list of strings
this would be a pain to support for a Path Type
The text was updated successfully, but these errors were encountered: