Test usqge of SQL's substr() with a UTF8 example. The ideal would be to
test with non-UTF8 code points, however it is impossible to perform such
a query: queries can only be unicode or utf8.
Places where InvalidQueryArgumentTypeError may be raised (i.e. all
current ones) may not know the query therefore it cannot be an
InvalidQueryError. The InvalidQueryArgumentTypeError is caught in
beets.library.Library._fetch() and an InvalidQueryError is then raised.
Improve #1290.
Replace previous InvalidQueryError with InvalidQueryArgumentTypeError
which extends the former as TypeError. However they lack context: the
query that caused the error.
Raise an InvalidQueryError when a shell-like expression cannot be parsed
by shlex.
Improve #1290.
Include import of __future__ features division, absolute_imports and
print_function everywhere. Don't add unicode_literals yet for it is
harder to convert.
Goal is smoothing the transition to python 3.
So far an invalid query won't be applied:
$ beet ls The Beatles year:196a
will be treaded as
$ beet ls The Beatles
With this commit it stops beets, returns 1 and produces
$ invalid query: u'196a' is not an int or a float
This applies to any querying and therefore on many command, plugins and
some configuration options.
Invalid queries exist on numeric fields and on regular expression usage.
Compile regular expression queries upon instantiation instead of upon
each match test.
The reporting can be improved (give more context). Fix#1219.
The initial idea for this refactor was motivated by the need to make
PluginQuery.match() have the same method signature as the match() methods on
other queries. That is, it needed to take an *item*, not the pattern and
value. (The pattern is supplied when the query is constructed.) So it made
sense to move the value-to-pattern code to a class method.
But then I realized that all the other FieldQuery subclasses needed to do
essentially the same thing. So I eliminated PluginQuery altogether and
refactored FieldQuery to subsume its functionality. I then changed all the
other FieldQuery subclasses to conform to the same pattern.
This has the side effect of allowing different kinds of queries (even
non-field queries) down the road.
