Skip to content

use _compression.BaseStream for lzma.LZMAFile #11166

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

Merged
merged 1 commit into from
Dec 15, 2023
Merged

use _compression.BaseStream for lzma.LZMAFile #11166

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions stdlib/lzma.pyi
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
import io
from _compression import BaseStream
from _typeshed import ReadableBuffer, StrOrBytesPath
from collections.abc import Mapping, Sequence
from typing import IO, Any, TextIO, overload
Expand Down Expand Up @@ -104,7 +104,7 @@ class LZMACompressor:

class LZMAError(Exception): ...

class LZMAFile(io.BufferedIOBase, IO[bytes]): # type: ignore[misc] # incompatible definitions of writelines in the base classes
class LZMAFile(BaseStream, IO[bytes]): # type: ignore[misc] # incompatible definitions of writelines in the base classes
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated to this MR:

I stared at this for a while, and I can't quite figure out what the purpose of inheriting from IO[bytes] here is. I found the discussion of typing.IO here python/typing#829 which seems to say typeshed's policy is to avoid the use of typing.IO.

I guess the concern is that because typing.IO isn't actually a Protocol, functions typed to accept a typing.IO argument require classes in the standard library to be subclasses of typing.IO to work as expected?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, yes, and yes :) Most of our uses of IO are legacy uses from years back, before we came up with the policy of mostly using narrower protocols for I/O related things. Nowadays, we recommend that our users don't use typing.IO, and we wouldn't usually start using it in a new class we were adding stubs for.

We could possibly think about changing this -- but, as you say, it comes at the risk of breaking user code that's already using typing.IO. So, best to consider it separately in another PR, if at all.

def __init__(
self,
filename: _PathOrFile | None = None,
Expand Down