CLN: parametrize test_nat_comparisons
Parametrize ``TestDatetime64SeriesComparison.test_nat_comparisons``
using ``operator`` module.

If this kind of cleanup is considered reasonable,
then I will go through the remaining tests in this test module.

- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

yes this type of cleanup is good. targeted PRs are the best.

cc @jbrockmendel if comments. i do not find this clearer than the status quo.

the lowest-hanging fruit in the tests/arithmetic directory are ones that do not use the box_with_array fixture

there are also very likely redundant tests that can be de-duplicated @jbrockmendel ok so you are -1 on this? -0.5, i.e. i dont think this is an improvement, but not a hill to die on if others have strong opinions ok closing this > -0.5, i.e. i dont think this is an improvement, but not a hill to die on if others have strong opinions

Parameterisation is beneficial when there a multiple test failures. It is sometimes easier to debug when all the passing and failing test cases are visible together.

This PR looked good to me. ok @ivanovmg can u merge master Merged master.
Also I renamed local variable ``operator`` into ``op`` for consistency with other test and not to confuse with module ``operator``.
However, probably more readable option would be ``operator_`` with a trailing underscore, so it is more clear that we are talking about the operator.
Alternatively, ``binary_operator`` - longer name, but more clear IMHO. > Parameterisation is beneficial when there a multiple test failures. It is sometimes easier to debug when all the passing and failing test cases are visible together.

This is true in a general sense, but I'd point out:

1) we have many tests where we don't parametrize these particular 6 methods

2) The 6 Series objects get created at test collection time, which increases the memory footprint of the test suite.  In isolation these 6 small Series is not a big deal, but we are already at a point where memory is causing the py38 windows build to fail regularly.

Again, not a hill worth dying on, just saying. thanks @ivanovmg 