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 }}
This repository was archived by the owner on Sep 9, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 9, 2026. It is now read-only.
Right now we don't really use Literal types anywhere, but we should.
For example, see the following signature:
@classmethoddeffrom_bytes(
cls: Type[T],
data: bytes,
protocol: str='protobuf',
compress: Optional[str] =None,
) ->T:
"""Build Document object from binary bytes :param data: binary bytes :param protocol: protocol to use. It can be 'pickle' or 'protobuf' :param compress: compress method to use :return: a Document object """
Here, protocol can only be 'pickle' or 'protobuf', so Literal['pickle', 'protobuf'] would be the most suitable type hint.
Changing that will require multiple other changes in order to keep mypy happy, since other code relies on protocol being str.
This issue is about adjusting the above, and identifying and fixing other similar instances (if they exists).
Is protobuf-array also a possible value for protocol in the intended context? (If not... maybe the parameter name protocol should be used to refer to two different things.)
I'm in favor of an enum over a Literal consisting of different strings, but I can see how the latter is easier for end users. I can seek out other instances of this same issue if this PR looks good.
Activity
srini047 commentedon Jun 26, 2023
Hey, @JohannesMessner I would like to work on this issue.
JoanFM commentedon Jun 26, 2023
hey @srini047 ,
It would be great if you can take up this issue.
bpshaver commentedon Oct 23, 2023
Is
protobuf-arrayalso a possible value forprotocolin the intended context? (If not... maybe the parameter nameprotocolshould be used to refer to two different things.)bpshaver commentedon Oct 23, 2023
Opened a PR.
I'm in favor of an enum over a
Literalconsisting of different strings, but I can see how the latter is easier for end users. I can seek out other instances of this same issue if this PR looks good.JohannesMessner commentedon Oct 24, 2023
The PR looks good, helping us with further instances of this problem would be great!
JoanFM commentedon Oct 24, 2023
Yes, it would be nice to make sure there are other instances or if we can close this
bpshaver commentedon Oct 24, 2023
I believe these parameters are candidates for similar treatment:
audio_codecaudio_formatvideo_codecBut there may be more
JoanFM commentedon Oct 24, 2023
They do seem nice candidates sure