Stop using Any in TypeVar bound to Database

[amogus07]

Description

This makes the type annotations in dbcore slightly stricter
https://peps.python.org/pep-0484/#covariance-and-contravariance

To Do

• Documentation. (If you've added a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• Changelog. (Add an entry to docs/changelog.rst to the bottom of one of the lists near the top of the document.)
• Tests. (Very much encouraged but not strictly required.)

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.46%. Comparing base (c9df7a9) to head (81e6dab).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6649   +/-   ##
=======================================
  Coverage   72.46%   72.46%           
=======================================
  Files         161      161           
  Lines       20710    20710           
  Branches     3276     3276           
=======================================
  Hits        15007    15007           
  Misses       4977     4977           
  Partials      726      726           

Files with missing lines	Coverage Δ
beets/dbcore/db.py	93.87% <100.00%> (ø)
beets/dbcore/query.py	90.86% <100.00%> (ø)
beets/dbcore/sort.py	92.52% <100.00%> (ø)
beets/library/migrations.py	96.49% <100.00%> (ø)
beets/library/models.py	87.03% <100.00%> (ø)
beets/util/diff.py	100.00% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[snejus]

What do we gain from this in practical terms?

[amogus07]

In Python, TypeVars are invariant by default. In practice, this means that, with the invariant TypeVar T, Model subclasses like LibModel would only be allowed to supply T or Database itself as type parameters and not subclasses of Database like Library. Previously, this intentional restriction was circumvented using default=Any as a workaround, which disables typechecking entirely as far as I understand.

def example(m: Model) -> None:
    return m.db # type: Any

. Now, by replacing T with the covariant T_co, subclasses of Model (or any other class using it) are allowed to use any subclass of Database, making Libmodel(Model[Library]) valid without using Any. Now, m.db from the example function is inferred as being of type Database rather than Any. I could've kept the default value in T_co and replaced it with "Database", but that would obscure the fact that Model is generic to consumers. As mentioned in one of the commit messages, I already found some incorrect type annotations in the library module where Model[Any] was (implicitly) used instead of Model[Library] which is more appropriate.

[snejus]

The main reason why we had Any there is that most of these classes that receive/depend on Model class do not care that it has a generic relationship to Database.

This is why I'm asking whether making this typing stricter has any practical benefits. From what I can see, it simply makes type definitions more verbose without a clear benefit.