optimise_fonts's return value could be better typed

[shmulvad]

The main function optimise_fonts and the other exposed functions using it return dict[str, typing.Any]. This is inconvenient for the users of the library as they will have no autocomplete and type safety. There are two possible ways you can solve it. I would recommend 1 here, although it will break backwards compatibility. You can use 2 if you really prefer dictionaries and don't want to break the backwards compatibility.

1. Using a dataclass:

Returning a suitable dataclass instead will allow users to access the values with dot notation:

from dataclasses import dataclass, field

@dataclass
class FontResult:
    css: set[str] = field(default_factory=set)
    fonts: dict[str, str] = field(default_factory=dict)
    chars: set[str] = field(default_factory=set)
    uranges: str = ''

Then you can return an instance of this instead of your dictionary:

font_res = FontResult()
...
font_res.chars = characters  # etc
...
return font_res

2. Using TypedDict:

Return a typed dictionary. The code would be something along these lines:

from typing import TypedDict


class FontResult(TypedDict):
    css: set[str]
    fonts: dict[str, str]
    chars: set[str]
    uranges: str


def optimise_fonts(...) -> FontResult:
    font_res = {'css': set(), 'fonts': {}, 'chars': set(), 'uranges': ''}
    ...
    return font_res

[vintagedave]

return dict[str, typing.Any]. This is inconvenient for the users of the library as they will have no autocomplete and type safety

Yes! This is a great point, and worried me when I wrote it. I had no idea how to represent multiple types in a type hint; without your feedback here I likely would have gone in the direction of writing a class. That's also because there are multiple places in code where an empty/default return value is laboriously constructed, which is ugly.

But both solutions you have here are new to me: both typed dict and data classes. I'm not attached to a dict per se, it just seemed a neat / Pythonic way to collect multiple items together. Thanks for the feedback and I'll research both, but I note the recommendation for (1) and will pay attention there.

[vintagedave]

Hi. I have been thinking about this for a while, and I'm still trying to figure out a solution that lets me retain the existing interface while adding another, in order not to break the library usage.

[shmulvad]

Using suggestion 2 would not change any runtime behaviour.