> is there a reason why it is not returning an actual list of paths?

I did not want to have the function return sometimes a string and other times a list of strings. I don't consider it a sane practice to have a function return an unknown type, it can break applications very badly. Keeping it a string means the same type, string, is the return type.

> i'm not sure what the use case of returning multiple paths is; i'm guessing that users want to search for file

Yes, this is correct. Please note that the XDG standard states the site specific data dirs ``$XDG_DATA_DIRS`` and site specific config dirs ``$XDG_CONFIG_DIRS``, but there is only a user specific data dir ``$XDG_DATA_HOME`` and a user specific config dir ``$XDG_CONFIG_HOME``.

> appdirs API -- should ideally not be tied in to platform-specific concerns.

That's why I tried to keep it backwards compatible and for *_config_dir APIs I provided the *_data_dir on Windows and Mac.

Even if we opt for site_*_dir_list APIs for multivalues, the API will be useful for *nix and the other two will only wrap the site_data_dir and we'll effectively have 4 APIs which essentially are identical due to wrapping and due to lack of dir lists. Please take this into account, too.


I think I prefer the site_config_dir_list variant as a disambiguation, although the site_config_dir API will probably remain unused on *nix *and* on Windows and Mac ``site_config_dir, site_data_dir, site_config_dir_litst and site_data_dir_list`` are essentially identical.


What do you think?