googlefonts / googlefonts/fontmake

do we need the FontProject class at all?

Open
#215 5 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
888
Forks
97
Avg merge
4d 52m
Merged PRs (30d)
1

Description

Currently the core of fontmake is all contained in a single `FontProject` class inside the `font_project` module.

However, instances of this class do not hold any state nor contain any data. All of the class's methods can be turned into either `@staticmethod` (where `self` is not used) or `@classmethod` (first argument is the class itself, rather than the instance).

The `__init__` constructor takes two arguments which are used to configure the module-level logger.
Now, this is wrong for several reasons and we shall get rid of that.

The loggers created by `logging` module are "sigletons", i.e. only one logger instance is created/returned by calls to `logging.getLogger`. This is so that loggers can be globally configured by clients.
Hence, in the case of fontmake, it does not make sense that every time one creates a `FontProject` instance, the verbosity level of the global module-level logger named `fontmake.font_project` can be modified at the instance level. In fact, it does not work like that.
Attempting to set a different verbosity the second time does not produce any change, because by design the `logging.basicConfig` can only configure the root logger once, and doesn't do anything if run again (which may seem counter-intuitive for a `verbose` argument in a class constructor).

This is why the logging docs say that one should never configure logging (let along the root logger) inside the library code itself, but only in the `main()` entry point.

So after taking away logging, there's nothing left for the FontProject instance, and all the methods can be turned either into static/class methods, or even better just plain functions.

This is somewhat similar to https://github.com/typemytype/booleanOperations/issues/24, which we addressed by keeping the class for compatibility and exporting the static methods as functions as well.

For fontmake, which AFAIK is not being used as a library by anyone (please correct me if I'm wrong), I think it's not needed to keep the class, but we can just turn all methods into functions.

Unless.. we do want to have the FontProject instance hold some data. Do we?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.