8000 Fix `TypeError` from `str(Path(...))` by barneygale · Pull Request #135 · jaraco/zipp · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix TypeError from str(Path(...)) #135

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
Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Fix TypeError from str(Path(...)) #135

wants to merge 3 commits into from

Conversation

barneygale
Copy link
Contributor
@barneygale barneygale commented Apr 25, 2025 •
edited
Loading

Make Path.__str__() return self.at rather than attempting to join the member path onto the zip file path.

When the ZipFile is named on the filesystem, the new behaviour produces a more straightforward string representation that is less likely to be mistaken for a real filesystem path.

When the ZipFile is unnamed, the new behaviour ensures that a TypeError isn't raised.

Resolves #134

@barneygale
Fix TypeError from str(Path(...))
c5320cc 
Make `Path.__str__()` return `self.at` rather than attempting to join the
member path onto the zip file path.

When the `ZipFile` is named, the new behaviour produces a more
straightforward string representation that is less likely to be mistaken
for a real filesystem path.

When the `ZipFile` is unnamed, the new behaviour ensures that a `TypeError`
isn't raised.

Resolves jaraco#134
@barneygale barneygale mentioned this pull request Apr 25, 2025
Open
@barneygale barneygale mentioned this pull request Apr 27, 2025
Open
@barneygale
Copy link
Contributor Author
barneygale commented Apr 30, 2025 •
edited
Loading

@jaraco courtesy ping to put this on your radar

This changes behaviour of str(zipp.Path(...)), so we'd need to add a .. versionchanged:: directive in the cpython docs.

I think the change is worthwhile, because the current behaviour:

  • Produces strings that can be mistaken for a real filesystem paths by a casual reader
  • Produces strings that mix forward and backward slashes on Windows
  • Raises a TypeError when the zip file doesn't have a name on the filesystem
  • Doesn't have a clear use case (as far as I can tell)
  • Is slightly less intuitive than returning the member path alone imo

IIUC, the current implementation is designed to be "lossless" - all the arguments to __init__() are represented in the __str__() return value. But is losslessness a requirement or even an expectation of __str__(), __int__(), etc? IMHO it's fine to omit contextual information (in this case, the ZipFile object) if the main value is represented. Furthermore the current implementation isn't truly lossless because Path("a", at="b.zip") and Path("a/b.zip") can't be distinguished from their string representations.

What do you think? Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

str(Path(...)) can raise TypeError
1 participant
@barneygale
0