platformdirs: Returning `Path` instead of `str` instances

As mentioned in https://github.com/ActiveState/appdirs/issues/79, I’ve been working on another fork of appdirs, but would rather hold off on publishing that and focus all efforts in one place.

I mostly have two changes in places:

Drop support for ancient python versions (there’s little point in a new library supporting Pythons that re long past their EOL, and that just holds back on keeping the library alive).
Change the return type of directories to Path instance, to make usage on consumer libraries easier. This kinda means it’s not a 100% drop-in replacement, but rather an upgrade (e.g.: like a major).

Maybe it would make sense to have a platformdirs==1.0.0 release, which is functionally identical to appdirs (to allow seamless switching), and then start merging in any non-backwards-compatible changes. Thoughts?

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 23 (22 by maintainers)

Commits related to this issue

Add API calls that return pathlib.Path instead of str objects Implements https://github.com/platformdirs/platformdirs/issues/3 — committed to papr/platformdirs by papr 3 years ago
Add API calls that return pathlib.Path instead of str objects Implements https://github.com/platformdirs/platformdirs/issues/3 — committed to papr/platformdirs by papr 3 years ago

Most upvoted comments

user_data_path
user_config_path
user_cache_path
user_state_path
user_log_path
site_data_path
site_config_path

And yes.

gaborbernat on Jul 22, 2021

Done by #27.

gaborbernat on Jul 23, 2021

Creating a class (which pathlib is) will always be slower than just a raw string. See https://github.com/psf/black/issues/1950 for a war story on this.

gaborbernat on Jul 23, 2021

so one could get a Appdirs(...., path_type=pathlib.Path/pathlib2.Path)

That sounds a lot like https://adamj.eu/tech/2021/07/10/python-type-hints-how-to-avoid-the-boolean-trap/, I think it’s better to have new method names for the path variant 😊

gaborbernat on Jul 20, 2021

As long as there’s one python 2 compatible release virtualenv will be fine. virtualenv plans to support Python versions two years past their grace period - https://gaborbernat.github.io/euro_python_2019/#/55; so will not drop Python 2 support until January 1st. But yeah PyPy2 support on virtualenv side might hold back virtualenv on Python 2 land for longer…

gaborbernat on Jul 11, 2021