Type/Behavior mismatch for "Tags" parameter of Creator.config_metadata

[IMayBeABitShy]

Currently, the method signature of Creator.config_metadata is as follows:

def config_metadata(
        self,
        *,
        Name: str,
        Language: str,
        Title: str,
        Description: str,
        LongDescription: Optional[str] = None,
        Creator: str,
        Publisher: str,
        Date: Union[datetime.datetime, datetime.date, str],
        Illustration_48x48_at_1: bytes,
        Tags: Optional[Union[Iterable[str], str]] = None,
        Scraper: Optional[str] = None,
        Flavour: Optional[str] = None,
        Source: Optional[str] = None,
        License: Optional[str] = None,
        Relation: Optional[str] = None,
        **extras: str,
    ):

The line Tags: Optional[Union[Iterable[str], str]] = None, implies that Tags may be either a string or a list of strings. Yet, there exists no code that handles the case where Tags is a list of strings rather than a single string, resulting in python-libzim raising an exception:

File "libzim/libzim.pyx", line 583, in libzim.Creator.add_metadata
TypeError: Argument 'content' has incorrect type (expected bytes, got list)

Potential fixes:

• add special case to Creator.start, Creator.add_metadata or Creator.config_metadata to handle type conversion by joining the list with ";" (Note: Type annotations of add_metadata() do not allow a list fo strings, this may need to be adjusted)
• Adjust the type annotations of Creator.config_metadata() to only allow str values for Tags

As you can see, this is a really minor issue and I'd simply open a pull request with the fix, but I am unsure whether the type annotation is right and the code wrong or vice versa.

[rgaudin]

I think the intent is good: we want to handle both here because both can be handy in a scraper context. You PR adding support for it would be welcome