tests: Complete the method lists

[nbraud]

• Add methods that do not return a Vector2
• Use Vector2.convert directly, rather than a lambda, so it has a human-meaningful name.

[AstraLuma]

Shouldn't this cause tests to fail?

class V(Vector2): pass

assert isinstance(Vector2.convert((1,2), Vector2)
assert isinstance(V.convert((1,2), V)

Oh, I see, it's because it's passing in a Vector2 in the test, so .convert() just short-circuits and passes the instance right back out.

This is still probably wrong.

[nbraud]

This is still probably wrong.

How so? As the commit message details, tests never redefine Vector2.convert in a subclass, so it's equivalent, and we get Vector2.convert as the function name instead of <lambda somehorriblestuff>, in tests and benchmark output.

[AstraLuma]

A subclass doesn't have to override it for it to return a subclass.

If .convert() is called on a subclass, it'll return that subclass if construction was involved. eg, MyVector.convert((1,2)) will return an instance of MyVector with no overrides necessary.

[nbraud]

Yes, this is true, but it's also not tested by anything in our testsuite (as far as I can tell), nor is it related to any of the tests that use UNARY_OPS.

Case in point, calling that lambda on something that isn't a (subclass of) Vector2, like a tuple, would expand to tuple.convert((1, 2)) and fail:

>>> l = lambda v: type(v).convert(v)
>>> l((1, 0))
AttributeError: type object 'tuple' has no attribute 'convert'

>>> l = Vector2.convert
>>> l((1, 0))
Vector2(1.0, 0.0)

As such, I don't think there is a way for a test that uses UNARY_OPS (whether with the lambda or with Vector2.convert) to be testing that behaviour, and there definitely is no test in the testsuite that does (because it would have broken with the lambda).

[AstraLuma]

Ok, fine. We should probably have other tests testing it, though.

[nbraud]

PS: The CI failure was caused by a mypy issue, so I added a type: ignore annotation as a workaround.