Refactor: use Literal in type hints

[JohannesMessner]

Right now we don't really use Literal types anywhere, but we should.
For example, see the following signature:

    @classmethod
    def from_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).

[srini047]

Hey, @JohannesMessner I would like to work on this issue.

[JoanFM]

hey @srini047 ,

It would be great if you can take up this issue.

[bpshaver]

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.)

[bpshaver]

Opened a PR.

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.

[JohannesMessner]

I can seek out other instances of this same issue if this PR looks good.

The PR looks good, helping us with further instances of this problem would be great!

[JoanFM]

Yes, it would be nice to make sure there are other instances or if we can close this

[bpshaver]

I believe these parameters are candidates for similar treatment:

• audio_codec

• audio_format

• video_codec

But there may be more

[JoanFM]

They do seem nice candidates sure