Page MenuHomePhabricator

packaging: coerce paths to strings
ClosedPublic

Authored by durin42 on Apr 16 2019, 5:55 PM.

Details

Summary

Experimentally passing the pathlib.Path to zipfile.ZipFile fails on at
least some Python versions. I've gotten frustrated enough I'd rather
just force them to be strings and move on.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

durin42 created this revision.Apr 16 2019, 5:55 PM
pulkit accepted this revision.Apr 16 2019, 6:21 PM
This revision was automatically updated to reflect the committed changes.

Argh. This change appears to be wrong (!) so I'm going to drop it.

Argh. This change appears to be wrong (!) so I'm going to drop it.

Eh? I don't see anything wrong with this. Casting a pathlib.Path to str should just work! In fact, it is necessary for older Python 3, as there was a long tail of stdlib functions that didn't accept pathlib.* when those types were first introduced. I believe 3.7 was the first release that fixed them all.

Argh. This change appears to be wrong (!) so I'm going to drop it.

Eh? I don't see anything wrong with this. Casting a pathlib.Path to str should just work! In fact, it is necessary for older Python 3, as there was a long tail of stdlib functions that didn't accept pathlib.* when those types were first introduced. I believe 3.7 was the first release that fixed them all.

At least one of the archive libraries can't cope with a destination being a Path but a source being a str, or something like that. zipfile can't (AFAICT) cope with Path objects on Python 3.5, but I worked around that by finding a Windows image at work that came with 3.7 already installed. :)