This was a helper for situations when Python 2 and 3 APIs returned bytes
and unicode, respectively. In these situation, we should nowadays know
which of the two we receive, so there's no need to wrap & hide the
`bytes.decode()` anymore (when it is still required).
Detailed justification:
beets/ui/__init__.py:
- command line options are always parsed to str
beets/ui/commands.py:
- confuse's config.dump always returns str
- open(...) defaults to text mode, read()ing str
beetsplug/keyfinder.py:
- ...
beetsplug/web/__init__.py:
- internally, paths are always bytestrings
- additionally, I took the liberty to slighlty re-arrange the code: it
makes sense to split off the basename first, since we're only
interested in the unicode conversion of that part.
test/helper.py:
- capture_stdout() gives a StringIO, which yields str
test/test_ui.py:
- self.io, from _common.TestCase, ultimately contains a
_common.DummyOut, which appears to be dealing with str (cf.
DummyOut.get)
used to work due to inconsistent mediafile implementation, but with
https://github.com/beetbox/mediafile/pull/64 (in mediafile >= 0.11.0)
list fields are None if non-existent, not the empty list
On Windows, converting command-line arguments (hopefully!!!) only needs
to deal with valid strings from the OS. So it is not really relevant to
test with non-UTF-8, non-surrogate bytes.
Unidecode 1.3.5 (a yanked PyPI version) changed the behavior of
Unidecode for some specific characters:
> Remove trailing space in replacements for vulgar fractions.
As luck would have it, our tests used the 1/2 character specifically to
test the behavior when these characters decoded to contain slashes. We
now pin a sufficiently recent version of Unidecode and adapt the tests
to match the new behavior.
Quoth the responses documentation:
> querystring is matched by default
Not sure how recent this is, unfortunately---but probably 0.17.0, since
that's the version where `match_querystring` was deprecated.
Makes the dispatch to the chosen backend simpler in the thumbnails
plugin. Given that ArtResizer is not only about resizing art anymore,
these methods fit there quite nicely.
- Adds a configuration that, when enabled, will append the style to genre
- Rationale is to have more verbose genres in genre tag of players that only support genre
This didn't cause any issues since we only use the shared instance
anyway, but logically it doesn't make a lot of sense for the backends
always using ArtResizer.shared (which they should be oblivious of).
