8000 Move pathlib implementation out of `__init__.py` by barneygale · Pull Request #118582 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

Move pathlib implementation out of __init__.py #118582

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
May 5, 2024
Merged

Move pathlib implementation out of __init__.py #118582

merged 2 commits into from
May 5, 2024

Conversation

barneygale
Copy link
Contributor
@barneygale barneygale commented May 4, 2024 •
edited
Loading

Use the __init__.py file only for imports that define the API, following the example of asyncio.

See https://discuss.python.org/t/make-pathlib-extensible/3428/172

@barneygale
Move pathlib implementation out of __init__.py
8000 d08bbc4 
Using the `asyncio` package as a model.
@barneygale barneygale requested a review from eryksun May 4, 2024 21:11
@barneygale
Copy link
Contributor Author

@eryksun you mentioned renaming _abc.py to _pathlib_abc.py on the forum. Do you mean something like this?

Lib/pathlib.py
Lib/_pathlib_abc.py
Lib/_pathlib_glob.py
Lib/_pathlib_local.py

... because that would speed up the import of pathlib._glob from the glob module I think.

@eryksun
Copy link
Contributor
eryksun commented May 4, 2024

Great if that really helps with performance. My issue was more trivial. I like to have easily recognizable names on tabs in my IDE. "_pathlib_abc.py" is a name that I can recognize in an instant without having to hover or use the document viewer.

@barneygale
Copy link
Contributor Author

Hm. If I thumb through the standard library, there are quite a few submodules with generic basenames: asyncio.log, ctypes.util, email.errors, re._constants etc. I don't really mind either way, but it seems more consistent with the rest of Lib/ to consider the entire package path as the name. Can you configure your IDE to do that perhaps?
8000

@eryksun
Copy link
Contributor
eryksun commented May 4, 2024 •
edited
Loading

No, not on tabs, and I wouldn't want qualified names on tabs. That's what the tree view of the documents viewer is for if I really need it. I know the standard library doesn't generally use easily recognizable module names in packages. That's why I qualified the asyncio example for what I personally prefer, and only for generic private names. Some names are easy for me to remember in context, such as "pool.py" in multiprocessing. It's just generic private names such as "_constants.py" that I wish had better names, since they aren't meant to be used in the public API anyway. But really almost anything is better than staring at a bunch of tabs labeled "__init__.py".

@barneygale
Copy link
Contributor Author

Well, the __init__.py problem is improved at least. I'm not sure about adding a pathlib_ prefix to the other module names - I suspect other folks might find it overly repetitive and out of line with the rest of the stdlib. I hope you'll eventually forgive me if I merge this as-is. I'm open to renaming the modules in future if it becomes more obviously the correct thing to do.

@barneygale barneygale merged commit d8d9491 into python:main May 5, 2024
31 checks passed
8000
SonicField pushed a commit to SonicField/cpython that referenced this pull request May 8, 2024
@barneygale @SonicField
Move pathlib implementation out of __init__.py (python#118582)
88246f7 
Use the `__init__.py` file only for imports that define the API, following the example of asyncio.
@PeterJCLaw
Copy link
Contributor

Great to see the work going into pathlib for the next version of Python :).

Apologies if this isn't the right place to bring this up and/or if this is already known/expected, but I wanted to highlight that moving the implementations of pathlib prevents pickles coming from Python 3.13 (specifically I'm testing at 3.13.0b2) being loaded on earlier versions of Python (the other way around works fine). I realise that this probably isn't something where backwards compatibility is expected and that moving pickles between versions maybe not desirable, though it is used in a few places -- notably Jedi does so.
I've seen that pickle supports the notion of fixing imports for various standard library moves, so I'm not sure if this is something which might be a candidate for including in those fix lists? (I realise this would need to be a fix applied to older versions of Python rather than to 3.13)

For Jedi I've worked around this pretty easily by adding a custom Unpickler, which I'm guessing might be what's expected?

I'm not sure what's expected around moves like this, so if the default is "nothing" that's probably fine! It might be nice to call out the refactoring in the release notes though?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@eryksun eryksun eryksun approved these changes

Assignees
No one assigned
Labels
skip issue skip news topic-pathlib
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@barneygale @eryksun @PeterJCLaw
0