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

list using alternative to multipath #24

Closed
RonnyPfannschmidt opened this issue Jul 20, 2021 · 8 comments
Closed

list using alternative to multipath #24

RonnyPfannschmidt opened this issue Jul 20, 2021 · 8 comments

Comments

@RonnyPfannschmidt
Copy link

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

@gaborbernat
Copy link
Member

this would be a pain to support for a Path Type

We could introduce the contract that path variants always return the first of the multipath. If users want multipath they would need to do: user_data_dir().split(os.pathsep), at which point they can cast the elements into Path if they'd wish to 🤔

@papr
Copy link
Contributor

papr commented Jul 23, 2021

We could introduce the contract that path variants always return the first of the multipath.

Alternatively, site_data_path could return a list of pathlib.Path objects if multipath=True was passed. Ideally, site_data_dir would return a list of strings in that case, too (as suggested by @RonnyPfannschmidt). But this wouldn't be backwards compatible, correct?

From what I can see, site_data_dir is the only affected API here, correct?

@gaborbernat
Copy link
Member

It also would mutate the type returned based on a boolean flag which I don't like at all 😬

@papr
Copy link
Contributor

papr commented Jul 23, 2021

We could introduce the contract that path variants always return the first of the multipath.

In other words, the multipath flag would have no effect on site_data_path. It will simply always return the first path, which is the default for site_data_dir if multipath is not set.

How come that there is a binary flag for this anyway? Wouldn't it make more sense to have two new api calls: site_data_dir_list and site_data_path_list?

@gaborbernat
Copy link
Member

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.

@papr
Copy link
Contributor

papr commented Jul 23, 2021

Because for dirs the return type does not change

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 site_data_dir is called with multipath=True.

@gaborbernat
Copy link
Member

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.

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.

@gaborbernat
Copy link
Member

We solved this for now by picking first for paths. str endpoints still work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants