I usually don't add changelog bullets for project metadata---maybe this is
misguided, but it's nice to have everything be relevant to how beets itself
works so the changelog doesn't get too boring. I also don't list documentation
improvements, for example.
This avoids multiple paths to setting values. It also moves the buffer check
into PathType.normalize, where it belongs. This is slightly faster than the
previous iteration: about 8 vs. 9 seconds to list about 13k songs on my
machine.
Replace links to ‘writing-plugin’ by internal links to ‘templ_plugins’.
Add small paragraph at the end of _templ_plugins to mention ‘inline’
plugin and the ‘Writing Plugins’ page.
- spans are now tracked via a list of dicts instead of 2 lists
previously (simpler code)
- extend_year_spans() pregenerates all possible ranges at plugin setup
stage
- a BucketError is now raised if declared bucket format not accepted
When Model objects (Albums and Items) are loaded from the database a lot of time is wasted checking if the object is dirty and if fields are fixed or flexattr.
This change alow bypassing these checks when we know that the data is correct ; it should only be used when loading Model from the database.
With this, listing all tracks in my test database (8200 items) takes 4 seconds while it took 31 seconds previously.
The motivation for this is to increase the performance of template evalutation.
Previously, the `model._formatted_mapping()` method returned a dictionary that
served as the environment (mapping of variable names to values) when evaluating
a template. To populate the dictionary, we iterated over all keys in the model,
formatted the values, and assigned it to the dictionary. This meant we
formatted every field, even if the template did not require it.
With this commit `_formatted_mapping()` does not return a populated dictionary
but a proxy (or view) instance. The object only knows about the model and the
keys it provides the formatted view for. If a variable is requested by the
template it computes the formatted value on the fly.
The class-based approach has one additional advantage: In the future, we can
separate the formatting logic from the database logic.
