Repository navigation
4.0rc2: Deprecation warnings during VOTable tests on MIPS platform #9749
Description
Header:
platform linux -- Python 3.8.0+, pytest-4.6.6, py-1.8.0, pluggy-0.13.0
Matplotlib: 3.0.2
Freetype: 2.10.1
Running tests with Astropy version 4.0rc2.
Running tests in .pybuild/cpython3_3.8/build.
Date: 2019-12-09T18:49:42
Platform: Linux-4.19.0-7-octeon-mips-with-glibc2.29
Executable: /usr/bin/python3.8
Full Python Version:
3.8.0+ (default, Nov 23 2019, 04:55:55)
[GCC 9.2.1 20191109]
encodings: sys: utf-8, locale: UTF-8, filesystem: utf-8
byteorder: little
float info: dig: 15, mant_dig: 15
Package versions:
Numpy: 1.17.4
Scipy: 1.3.3
Matplotlib: 3.0.2
h5py: 2.10.0
Pandas: not available
astropy-helpers: 3.2.2
Using Astropy options: remote_data: none.
rootdir: /<<PKGBUILDDIR>>, inifile: setup.cfg
plugins: mpl-0.10, remotedata-0.3.2, openfiles-0.4.0, doctestplus-0.5.0, astropy-header-0.1.1, arraydiff-0.3
collected 14136 items / 30 skipped / 14106 selected
With 4.0rc2, I get a number of errors on our "mipsel" and "mips64el" platforms (32/64 bit little endian). They all appeare in astropy/io/votable/tests/vo_test.py and look like:
________________ ERROR at setup of TestFixups.test_implicit_id _________________
RuntimeWarning: invalid value encountered in equal
The above exception was the direct cause of the following exception:
self = <class 'astropy.io.votable.tests.vo_test.TestFixups'>
def setup_class(self):
> self.table = parse(
get_pkg_data_filename('data/regression.xml')).get_first_table()
astropy/io/votable/tests/vo_test.py:197:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
astropy/utils/decorators.py:521: in wrapper
return function(*args, **kwargs)
astropy/io/votable/table.py:166: in parse
return tree.VOTableFile(
astropy/io/votable/tree.py:3567: in parse
tag_mapping.get(tag, self._add_unknown_tag)(
astropy/io/votable/tree.py:3478: in _add_resource
resource.parse(self, iterator, config)
astropy/io/votable/tree.py:3279: in parse
tag_mapping.get(tag, self._add_unknown_tag)(
astropy/io/votable/tree.py:3225: in _add_table
table.parse(iterator, config)
astropy/io/votable/tree.py:2499: in parse
self.array = self._parse_tabledata(
astropy/io/votable/tree.py:2615: in _parse_tabledata
vo_reraise(e, config, pos)
astropy/io/votable/exceptions.py:119: in vo_reraise
raise exc
astropy/io/votable/tree.py:2608: in _parse_tabledata
vo_reraise(
astropy/io/votable/exceptions.py:119: in vo_reraise
raise exc
astropy/io/votable/tree.py:2605: in _parse_tabledata
value, mask_value = parsers[i](
astropy/io/votable/converters.py:543: in parse
value, mask = parse(x, config, pos)
astropy/io/votable/converters.py:718: in _parse_permissive
return f, self.is_null(f)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <astropy.io.votable.converters.Double object at 0x66da6928>, value = nan
def _is_null(self, value):
> return value == self.null
E DeprecationWarning: /<<PKGBUILDDIR>>/.pybuild/cpython3_3.8/build/astropy/io/votable/tests/data/regression.xml:162:6: DeprecationWarning: elementwise comparison failed; this will raise an error in the future. (in row 1, col 'doublearray')
astropy/io/votable/converters.py:652: DeprecationWarning
Since in my 4.0rc1 tests I had to mask warning-as-error, I can't tell whether this happened before.
The same appears as failure in test_table and others. Full build log here.
Activity
pllim commentedon Dec 9, 2019
@tomdonaldson , can you check if this is something you added recently?
tomdonaldson commentedon Dec 9, 2019
@olebole Do you know of previous version(s) where this definitely worked?
olebole commentedon Dec 10, 2019
It worked in 3.2.3.
pllim commentedon Dec 10, 2019
By the way, the presence of a warning doesn't mean that it didn't emit warning before. It is just that in #7928 , we decided to be very strict and turn all warnings into errors.
As far as I can see, the code in question has not changed for 8 years.
astropy/astropy/io/votable/converters.py
Lines 651 to 652 in 2e96299
pllim commentedon Dec 10, 2019
The easiest solution is to ignore this warning if @tomdonaldson does not have a problem with that.
pllim commentedon Dec 10, 2019
For the record, the Python 3.8 on Travis CI didn't pick up this warning. 🤷♀
https://travis-ci.org/astropy/astropy/jobs/623259373
pllim commentedon Dec 10, 2019
Maaaaybe there is a double float in the data that became
nanin this 32-bit setting. But we have 32-bit CI and didn't see this failure:astropy/.circleci/config.yml
Lines 33 to 35 in 2e96299
Example log: https://circleci.com/gh/astropy/astropy/55962
olebole commentedon Dec 10, 2019
@plim
The 32-bit platforms are not identical. i386 still uses the 387 "coprocessor" with 80bit internal doubles and seems to behave differently sometimes (#9694). However, our other 32-bit platform (armhf, also little endian) does not show these depcrecation warnings, which is a bit mystic.
I can ofcourse just switch off these warnings in the Debian package, since they don't really show a failure. So, if they are seen as minor problem, this is fine with me. I just try to be a bit more nitpicky when it comes to release candidates ;-)
pllim commentedon Dec 10, 2019
@olebole , that is understandable and we are very grateful that you are doing all these extra tests!
I'd defer to @tomdonaldson on a final decision of how to handle this. I think he is currently investigating.
tomdonaldson commentedon Dec 10, 2019
Yes, thanks @olebole for identifying this issue!
With this being an ignorable warning (and not apparent at all on the CI configurations), I'm comfortable moving ahead with the release without addressing this issue.
That said, I'd love to understand the details of why this is happening, but we can explore that in the background non-urgently. In particular, it would be nice to verify that we're seeing this because of the stricter handling of warnings (#7928) rather than resulting from some other change.
pllim commentedon Apr 30, 2021
We're preparing for 4.3rc soon. I wonder if this is still a problem. (The offending
==check is still there, so probably...)bsipocz commentedon Oct 22, 2024
Is this still an issue? It first appeared with py3.8, which got removed since and I sense that we haven't seen this error resurfacing anywhere else. Do we still support those platforms where it popped up?
olebole commentedon Oct 22, 2024
This is not an issue anymore. I now pragmatically switched off turning DeprecationWarnings into errors because while DeprecationWarnings are important during development, they are misleading for a released package to check if the package is still working (which is one of the goals of our Debian CI test). Therefore, I unfortunately now can't say whether this would still happen, and we probably can just close it.