TST: Table data type comparison fails with numpy-dev

These are new failures, probably from numpy-dev, which is now 1.21.dev after the release of 1.20.

One example (others are variants of such comparisons):

>       assert col.dtype == dtype_expected
E       AssertionError: assert dtype('O') == dtype('S1')
E        +  where dtype('O') = <MaskedColumn name='col0' dtype='object' length=8>\n 0\n 1\n 2\n 3\n 4\n 5\n 6\n--.dtype

Affected tests:

• astropy/table/tests/test_masked.py::TestTableInit::test_init_from_sequence_data_numeric_untyped[shape0-S]
• astropy/table/tests/test_masked.py::TestTableInit::test_init_from_sequence_data_numeric_untyped[shape0-U]
• astropy/table/tests/test_masked.py::TestTableInit::test_init_from_sequence_data_numeric_untyped[shape1-S]
• astropy/table/tests/test_masked.py::TestTableInit::test_init_from_sequence_data_numeric_untyped[shape1-U]
• astropy/table/tests/test_masked.py::TestTableInit::test_init_from_sequence_data_numeric_untyped[shape2-S]
• astropy/table/tests/test_masked.py::TestTableInit::test_init_from_sequence_data_numeric_untyped[shape2-U]
• astropy/table/tests/test_pprint.py::test_html_escaping
• docs/table/masking.rst::masking.rst

Is this a matter of updating the expected results, or is there some compatibility bug to be fixed – @mhvk or @taldcroft ?

[taldcroft]

See https://github.com/numpy/numpy/issues/18425. I’m marking this as upstream fix needed. If they can’t fix it then we will need to do some deeper changes to Table code. I’d suggest closing #11318.

[mhvk]

Very weird indeed! Hopefully it will auto-fix in a week or so…