Perhaps you could use a try-except import to check if pathlib is available, and instead provide an option to disable this behavior. This would make Path objects "just work" out of the box on Python 3, without affecting Python 2 in any way. The main impact would be on projects maintaining compatibility with both.

Sure.

I've changed the decorator to try-except the pathlib import, fallling back to the usual behavior.

One drawback of it, like you've mentioned, is that it will break for any project that doesn't have a pinned version and has pathlib available. The solution is simple though (wrapping value in str()) and maybe documenting/alerting this behavior is enough?

I like that solution, because again, like you've mentioned, we get Path objects out of the box when it is available.

I do think the pathlib support should be an opt-in. Otherwise, this becomes a major backward incompatible change since basically everyone with Python 3 has to update all their uses and there's no way to have gradual adoption.

Back to this.

@pradyunsg Would incrementing the major version be a valid compromise?

I like @keturn 's suggestion of having a separate entry point for pathlib.Path. Changing behaviour underneath people's feet and breaking 2/3 compatibility isn't great, but it would be nice to give people access to Paths (because they're great).

As a first pass, I would subclass the AppDirs object like this in a separate module:

class AppPaths(AppDirs):
    def user_data_dir(self):
        s = super(AppPaths, self).user_data_dir()
        return Path(s)

    ...

However, to keep with the zero-dependency, vendorisable structure of this library, the whole thing would need to be done in an if block.

appdirs wouldn't benefit from Paths being great, but everyone who's making the correct decision of A) using modern python and B) using Paths, would have their choices validated and have the added convenience.

I like that suggestion. I don't mind implementing it, if everyone agrees.