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

Adding to stdlib/pathlib? #265

Open
matterhorn103 opened this issue Feb 8, 2024 · 13 comments
Open

Adding to stdlib/pathlib? #265

matterhorn103 opened this issue Feb 8, 2024 · 13 comments

Comments

@matterhorn103
Copy link

Hi, I love this module and use it all the time. Many thanks for everyone's work!

Given platformdirs provides such key functionality with a fairly small footprint, is it insane to think that maybe it could be added to the Python standard library?

Given that pathlib already has Path.home(), maybe it could just be added to pathlib? Accessed with from pathlib import PlatformDirs? And then function identically to the way it does now?

@gaborbernat
Copy link
Member

This is a question to the core developers, however as far as I know, there's been an active effort to have less in the standard library as it's easier to update . 🤔 You can open an issue for the core developers at https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

@gaborbernat
Copy link
Member

Please link to this issue if you open an issue there, thanks!

@matterhorn103
Copy link
Author

matterhorn103 commented Feb 8, 2024

Fair enough. I started a discussion thread on the Python ideas board. :)

@matterhorn103
Copy link
Author

The reception was cautiously positive I'd say. The utility was definitely recognised.

Actually they didn't feel size of the stdlib is an issue – only whether users benefit more from the functionality being in the stdlib or available as a package. Their main concerns being:

  1. the frequency of new releases that platformdirs receives – but this seems mostly to do with your release policy of making new releases for pretty much every commit, correct?
  2. feature updates would be only possible at most once a year, and fixes would be slow to release and permeate through the Python ecosystem.

As a current maintainer, your opinion is the most important one here. Do you think users would benefit significantly from having it as a separate package with the possibility of rapid updates? And how often are breaking changes likely, in your view?

To me as an outsider, the pace of change of operating systems seems slow enough that stability feels like not really a concern.

@gaborbernat gaborbernat reopened this Feb 10, 2024
@gaborbernat
Copy link
Member

From my point of view there's benefit in both. It could even operate the same way importlib.resources does today where it is still released on its own but periodically mirrored into the standard library.

@gaborbernat
Copy link
Member

And yes, I think the project is stable enough nowadays and we don't plan any major changes.

@ofek
Copy link
Collaborator

ofek commented Feb 10, 2024

Maybe going into the standard library we could fix that macOS issue? I forget which one but it would be a major change.

@gaborbernat
Copy link
Member

Yeah we could have another round of deep review before we cut over, I would only do that though if you get verbal acord that the project would be accepted into the standard library, probably in a mirrored fashion as is importlib.resources is.

@hugovk
Copy link
Contributor

hugovk commented Feb 10, 2024

There are no verbal agreements, the steps for acceptance would be to find a core dev to sponsor, write up a PEP, submit it for community discussion (and update the PEP if needed), then submit it to the steering council for acceptance. PEP 1 has the details.

A good reference is PEP 680 ("tomllib: Support for Parsing TOML in the Standard Library"), that added (the read-only parts of) tomli to the stdlib.

A mirrored fashion sounds sensible, it would make it easier to contribute bug fixes and new features. The common parts of tomli and tomlib remain very similar too. (I recently checked and they were almost identical.)

@matterhorn103
Copy link
Author

Yes, it would maybe be a good opportunity to tidy up some things or change some things if you guys wanted. In a way, it's a chance for any last really big breaking changes. Namespaces, for example, if there were any lingering regrets from the past however many years.

I also wondered whether, for a PEP proposal, you might see it as desirable to slim down the package by only returning the paths as Path objects, whereas currently everything is doubled for both Paths and strings, right? Just an idea though.

@matterhorn103
Copy link
Author

By the way, since no one really asked for my opinion and I was the one who came here with irritating ideas keen to make more work for everyone – I'm very happy to contribute in any way I can :)

@gaborbernat
Copy link
Member

By the way, since no one really asked for my opinion and I was the one who came here with irritating ideas keen to make more work for everyone – I'm very happy to contribute in any way I can :)

It would be great if you could write up the PEP proposal, I would be happy to review it and push it through. We can be co authors in that sense if you're fine with that 👋

@matterhorn103
Copy link
Author

I can have a stab at it, sure. As long as you don't mind a multitude of questions about the implementation :)

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

4 participants