You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support pathlib.Path objects wherever possible #14893
This is a 'big picture' issue but we should in general make sure that anywhere that accepts filenames/paths in astropy can accept pathlib.Path objects. This is in the standard library and is a very convenient way of defining file paths. A lot of parts of astropy should already work with this, but as @nstarman found there are still places where this is not the case (astropy/astropy-iers-data#1 (comment)).
Yes but I was wondering whether we might be able to auto detect cases - if it was possible to intercept all function calls (similar to sys.setprofile but with access to the args/kwargs), we could detect all strings that match files that exist with os.path.exists and replace them with Path and see what breaks. I can try and investigate a little whether something like this might exist.
If we want to discover via our unit tests, we can hunt down the tmpdir and tmp_path usage, and then see where we are passing in actual Path objects and where we need to recast as str first. Otherwise, I am not sure how you can smoke them out besides reading 10+ years worth of code.
I'm trying to redo the machinery for how files i/o is handled in astropy. It seems like in some places code works just fine with pathlib and some places filenames need to be strings. I would like to go over this in 3 steps. Let me know if folks have any ideas/suggestions here:
Depends what the decorator is for and what problem we are trying to solve, which isn't clear to me right now.
I guess one issue to solve would be to handle overwrite more consistently across astropy (#15350) and that may be solvable with a decorator.
Activity
pllim commentedon Jun 1, 2023
How do we know when this is done? Isn't it better to open issue for specific area of the code as we find them?
astrofrog commentedon Jun 1, 2023
Yes but I was wondering whether we might be able to auto detect cases - if it was possible to intercept all function calls (similar to sys.setprofile but with access to the args/kwargs), we could detect all strings that match files that exist with
os.path.existsand replace them with Path and see what breaks. I can try and investigate a little whether something like this might exist.pllim commentedon Jun 1, 2023
If we want to discover via our unit tests, we can hunt down the
tmpdirandtmp_pathusage, and then see where we are passing in actualPathobjects and where we need to recast asstrfirst. Otherwise, I am not sure how you can smoke them out besides reading 10+ years worth of code.ManonMarchand commentedon Jun 7, 2023
It could be done by using the Ruff rules about pathlib
https://beta.ruff.rs/docs/rules/#flake8-use-pathlib-pth
nstarman commentedon Jun 7, 2023
Unfortunately not. This isn't about replacing
os.pathoperations but supportingPathobjects where we currently only support strings.MridulS commentedon Feb 18, 2024
I'm trying to redo the machinery for how files i/o is handled in astropy. It seems like in some places code works just fine with
pathliband some places filenames need to be strings. I would like to go over this in 3 steps. Let me know if folks have any ideas/suggestions here:str | PathLike.pllim commentedon Feb 19, 2024
@saimn , what do you think about decorator option? If anything is going to break, it would probably be
astropy.io.fits. 😬saimn commentedon Feb 20, 2024
Depends what the decorator is for and what problem we are trying to solve, which isn't clear to me right now.
I guess one issue to solve would be to handle
overwritemore consistently across astropy (#15350) and that may be solvable with a decorator.