I'm trying to improve the type annotations in beets/plugins.py, and I noticed that the plugin API deals with item and album types really weirdly. Plugins are expected to (optionally) define item_types and album_types (which are not defined in the BeetsPlugin superclass, losing out on type information), which are then dynamically queried using getattr(..., f"{cls.__name__.lower()}_types") for the Item and Album classes. The same applies to {item,album}_queries. See here.
Getting good type-checking with such a system is really difficult, and it doesn't look like this is used for anything more than the Item and Album types. I propose deprecating any functions relying on such a system (e.g. plugins.types() and plugins.named_queries()). There are two possible solutions here:
Support the possibility of other kinds of objects. Define a single field for {item,album}_types, as a dict mapping from the kind of object (either as a string or the Item / Album classes) to a list of database types specific to that kind of object.
Only allow for Item and Album. Explicitly define item_types and album_types in BeetsPlugin and provide plugins.item_types() and plugins.album_types().
I'm happy to make a PR implementing either solution. Regardless of what is picked, the old functions can be maintained for backward compatibility with external code (should any exist?).
I'm trying to improve the type annotations in
beets/plugins.py, and I noticed that the plugin API deals with item and album types really weirdly. Plugins are expected to (optionally) defineitem_typesandalbum_types(which are not defined in theBeetsPluginsuperclass, losing out on type information), which are then dynamically queried usinggetattr(..., f"{cls.__name__.lower()}_types")for theItemandAlbumclasses. The same applies to{item,album}_queries. See here.Getting good type-checking with such a system is really difficult, and it doesn't look like this is used for anything more than the
ItemandAlbumtypes. I propose deprecating any functions relying on such a system (e.g.plugins.types()andplugins.named_queries()). There are two possible solutions here:Support the possibility of other kinds of objects. Define a single field for
{item,album}_types, as adictmapping from the kind of object (either as a string or theItem/Albumclasses) to a list of database types specific to that kind of object.Only allow for
ItemandAlbum. Explicitly defineitem_typesandalbum_typesinBeetsPluginand provideplugins.item_types()andplugins.album_types().I'm happy to make a PR implementing either solution. Regardless of what is picked, the old functions can be maintained for backward compatibility with external code (should any exist?).