Add extra checks for the presence of specific field (artists, title,
id, tracklist) when parsing a Release from discogs, failing gracefully
if the fields could not be found.
Add a test for releases without required fields.
Improve the robustness of `get_album_info()` by preferring the use of
`get()` over accesing the dictionary keys directly for several fields,
plus adding extra checks for fields that depend on nested containers on
the Release data.
Add a test for parsing a release that contains a minimal amount of
fields.
This is the payoff from the earlier refactorings: the control flow is now
consistent and clear, and the two factors (time vs. number, equal-chance or
not) are orthogonal. See also #2322.
Previously "pretend" mode (a.k.a. dry run mode) passed the command to be
printed directly to _log.info, whose first argument is technically a
format string. Thus the command string was parsed for replacement fields, such
as '{foo}', which could cause the format evaluation to fail if the filenames
contained in the command contained valid (or partially valid) replacement fields.
This fix simply inserts an argument '{0}' to the call to _log.info, which is a
format string that simply evaluates to the second argument to _log.info (the
command string). By doing this, the command string is not parsed for replacement
fields.
Discog plugin overrides the global logging for `requests` for a reason
that seems no longer valid.
I can't seem to reproduce the logging behavior mentioned in the
preceding comment, so I'm removing it.
If we do want to modify `requests` logging in the future, then we should
hook it into beets verbose logging.
* Readability and consistency
* Better logging: warn by default for attributes that were not found,
but don't drown user with info when everything is going well.
* I don't see DefaultList be really helpful in many other cases, so having
a beets.util.collections module (which could also conflict with the collections
module from standard library) with only that in it is a little silly.
* It was elegant and concise, but there are implementation issues: it is not
recommended to subclass builtin types, but the alternatives differ between python
2 and 3 (subclass sequence or container or collections.abc?), moreover,
interpreters can differ in the way they map syntaxic sugar to magic functions.
* Also, slicing and negative indexing could do weird things, so the class wouldn't
be really intuitive and simple at the same time
