Replaced the usage of custom function assert_equal with np.testing.assert_equal by Harsh-pandya · Pull Request #15839 · astropy/astropy

Harsh-pandya · 2024-01-10T01:17:41Z

Change Description:

Performed removals

assert_equal()
assert_almost_equal()
assert_true()

Description

This pull request is to address ...

Fixes #15782

By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

… with np.testing.assert_equal Signed-off-by: Harsh-pandya <[email protected]>

github-actions · 2024-01-10T01:18:07Z

github-actions

Welcome to Astropy 👋 and congratulations on your first pull request! 🎉

A project member will respond to you as soon as possible; in the meantime, please have a look over the Checklist for Contributed Code and make sure you've addressed as many of the questions there as possible.

If you feel that this pull request has not been responded to in a timely manner, please send a message directly to the development mailing list. If the issue is urgent or sensitive in nature (e.g., a security vulnerability) please send an e-mail directly to the private e-mail [email protected].

github-actions · 2024-01-10T01:22:57Z

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

Signed-off-by: Harsh-pandya <[email protected]>

…with np.testing.assert_equal Signed-off-by: Harsh-pandya <[email protected]>

…t_equal with np.testing.assert_allclose Signed-off-by: Harsh-pandya <[email protected]>

Signed-off-by: Harsh-pandya <[email protected]>

Harsh-pandya · 2024-01-10T04:27:38Z

Hello @dhomeier, I completed the change mentioned in the issue. But, the following are the errors received in the Git workflow can you please help me with those?

Check if towncrier change log entry is correct
Precommit.ci
ruff.....................................................................Failed
- hook id: ruff
- exit code: 1
- files were modified by this hook
```
astropy/io/ascii/tests/test_c_reader.py:54:25: PT009 Use a regular `assert` instead of unittest-style `assert_`
```
Over here the function provided by np.testing is assert_. This function is the replacement for the assert_true in common.py.

Apart from this, all the tests ran successfully except 3 failed in my local I have attached a screenshot for those. This failure where in the docs file.

neutrinoceros

Thanks for you contribution !
Just a general comment on style: in astropy, numpy testing function are usually imported one of the following ways

from numpy.testing import assert_array_equal
import numpy.testing as npt

dhomeier · 2024-01-10T14:27:20Z



 # Compatibility functions to convert from nose to pytest


Suggested change

# Compatibility functions to convert from nose to pytest

Comment just related to the removed functions, so this can all be deleted.

dhomeier · 2024-01-10T14:33:33Z

2. Over here the function provided by np.testing is assert_. This function is the replacement for the assert_true in common.py.

I think the idea was rather to replace those with a simple assert as in

                        assert not isinstance(t2[name][i], str) and np.isnan(t2[name][i]

According to the docs npt.assert_ seems only useful for optimised code, and I don't think we ever need that in our unit tests.

dhomeier · 2024-01-10T14:44:40Z

Just a general comment on style: in astropy, numpy testing function are usually imported one of the following ways

from numpy.testing import assert_array_equal

import numpy.testing as npt

In addition, using the former for assert_almost_equal would allow to leave test bodies essentially unmodified.

As for assert_equal I am not sure if the intention was to use anything at all but a simple assert a == b –
@eerovaher , do the better failure diagnostics you mentioned in #15782 apply here as well (if one does not want to specify a custom error message)?

Last but not least @Rohit-Pujari has already begun work on this same task in #15787 – I don't know if there is still a perspective for completing that PR after college classes have resumed.

dhomeier · 2024-01-10T14:47:10Z

Apart from this, all the tests ran successfully except 3 failed in my local I have attached a screenshot for those. This failure where in the docs file.

The actual detailed errors must be further up in the full test log, but since doc build and tests are passing in the CI, I would not worry too much about that.

pllim · 2024-01-10T15:04:41Z

Gotta do something about that pre-commit rule.

dhomeier · 2024-01-10T15:13:33Z

You mean remove the rule? 🤔
PT009 does not seem to have any clue about numpy's assert_, so maybe that is something to consider, even if we are not testing in optimised mode atm.

But there were some real fixes of unused or misplaced imports that should be addressed before pushing upstream, @Harsh-pandya . Though I have no idea how the imports would have become unsorted by just removing one – perhaps you need to remove the following blank line as well?

pllim · 2024-01-10T15:47:31Z

Not sure how to properly ignore the rule but I think it should be done locally as needed only. Maybe @eerovaher or @nstarman can advise. Thanks!

eerovaher · 2024-01-10T15:59:24Z

@dhomeier asked

As for assert_equal I am not sure if the intention was to use anything at all but a simple assert a == b –
@eerovaher , do the better failure diagnostics you mentioned in #15782 apply here as well (if one does not want to specify a custom error message)?

It's usually best to use the numpy.testing helpers for checking array-like collections of numerical values, with the possible exception of checking strict equality, but for anything else I think pytest introspection is better. I am not aware of any good reasons to use np.testing.assert_(). Have a look at these examples:

Test for lists of numbers:

import numpy as np


values = [1, 2, 3]


def test_example_1():
	assert [1, 3, 3] == values


def test_example_2():
    assert np.array_equal([1, 3, 3], values)


def test_example_3():
    np.testing.assert_array_equal([1, 3, 3], values)


def test_example_4():
	np.testing.assert_([1, 3, 3] == values)

Traceback:

============================================== FAILURES ===============================================
___________________________________________ test_example_1 ____________________________________________

    def test_example_1():
>   	assert [1, 3, 3] == values
E    assert [1, 3, 3] == [1, 2, 3]
E      At index 1 diff: 3 != 2
E      Use -v to get more diff

test_example.py:8: AssertionError
___________________________________________ test_example_2 ____________________________________________

    def test_example_2():
>       assert np.array_equal([1, 3, 3], values)
E       assert False
E        +  where False = <function array_equal at 0x7f3c07d43eb0>([1, 3, 3], [1, 2, 3])
E        +    where <function array_equal at 0x7f3c07d43eb0> = np.array_equal

test_example.py:12: AssertionError
___________________________________________ test_example_3 ____________________________________________

    def test_example_3():
>       np.testing.assert_array_equal([1, 3, 3], values)

test_example.py:16: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

args = (<built-in function eq>, [1, 3, 3], [1, 2, 3])
kwds = {'err_msg': '', 'header': 'Arrays are not equal', 'strict': False, 'verbose': True}

    @wraps(func)
    def inner(*args, **kwds):
        with self._recreate_cm():
>           return func(*args, **kwds)
E           AssertionError: 
E           Arrays are not equal
E           
E           Mismatched elements: 1 / 3 (33.3%)
E           Max absolute difference: 1
E           Max relative difference: 0.5
E            x: array([1, 3, 3])
E            y: array([1, 2, 3])

/usr/lib/python3.10/contextlib.py:79: AssertionError
___________________________________________ test_example_4 ____________________________________________

    def test_example_4():
>   	np.testing.assert_([1, 3, 3] == values)
E    AssertionError

test_example.py:20: AssertionError

Test for strings:

import numpy as np


message = "Expected string output."


def test_example_1():
	assert "Expectd String  output." == message


def test_example_2():
    np.testing.assert_array_equal("Expectd String  output.", message)


def test_example_3():
	np.testing.assert_("Expectd String  output." == message)

Traceback:

============================================== FAILURES ===============================================
___________________________________________ test_example_1 ____________________________________________

    def test_example_1():
>   	assert "Expectd String  output." == message
E    AssertionError: assert 'Expectd String  output.' == 'Expected string output.'
E      - Expected string output.
E      ?       -  ^
E      + Expectd String  output.
E      ?         ^     +

test_example.py:8: AssertionError
___________________________________________ test_example_2 ____________________________________________

    def test_example_2():
>       np.testing.assert_array_equal("Expectd String  output.", message)

test_example.py:12: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

args = (<built-in function eq>, 'Expectd String  output.', 'Expected string output.')
kwds = {'err_msg': '', 'header': 'Arrays are not equal', 'strict': False, 'verbose': True}

    @wraps(func)
    def inner(*args, **kwds):
        with self._recreate_cm():
>           return func(*args, **kwds)
E           AssertionError: 
E           Arrays are not equal
E           
E           Mismatched elements: 1 / 1 (100%)
E            x: array('Expectd String  output.', dtype='<U23')
E            y: array('Expected string output.', dtype='<U23')

/usr/lib/python3.10/contextlib.py:79: AssertionError
___________________________________________ test_example_3 ____________________________________________

    def test_example_3():
>   	np.testing.assert_("Expectd String  output." == message)
E    AssertionError

test_example.py:16: AssertionError

…rts for numpy testing package. Also removed the unused import in common.py file. Signed-off-by: Harsh-pandya <[email protected]>

dhomeier · 2024-01-10T16:22:50Z

It's usually best to use the numpy.testing helpers for checking array-like collections of numerical values, with the possible exception of checking strict equality, but for anything else I think pytest introspection is better. I am not aware of any good reasons to use np.testing.assert_(). Have a look at these examples:

Thanks; I don't see much benefit in assert assert np.array_equal(), but np.testing.assert_array_equal certainly offers more useful info especially for large arrays!
I suppose assert np.testing.assert_ may only become useful if one creates a custom msg, but since I don't see a clear case for testing .pyo files, I'd leave it at assert there (and keep PT008 enabled).

dhomeier

As discussed I think using just assert_allclose and assert_equal from np.testing will be enough.
Not sure exactly how to make Ruff happy about the import order; perhaps it will be best to let it sort this out itself in the pre-commit hook. So if possible, apply the pre-commit fixes locally on your next commit before pushing. Thanks!

dhomeier · 2024-01-10T16:54:35Z

+import numpy as np
+import numpy.testing as npt
+import pytest
 from contextlib import nullcontext
 from io import BytesIO
 from textwrap import dedent


Suggested change

import numpy as np

import numpy.testing as npt

import pytest

from contextlib import nullcontext

from io import BytesIO

from textwrap import dedent

from contextlib import nullcontext

from io import BytesIO

from textwrap import dedent

import numpy as np

import pytest

from numpy.testing import assert_allclose, assert_equal

Frankly I have no idea what import order Ruff wishes to enforce, but the previous form was accepted, so apparently alphabetical order within a block is fine...
I personally prefer the option of using assert_* directly; since the old custom functions will be removed entirely, I don't think there is much risk of confusion. But that is up for discussion.

ruff is configured to the standard isort settings: first sort by package origin (standard library, third party, first party, local) then alphabetically within those blocks with import X preceding from X import.

dhomeier · 2024-01-10T16:56:02Z

+                        npt.assert_(
                            not isinstance(t2[name][i], str) and np.isnan(t2[name][i])
                        )


Suggested change

npt.assert_(

not isinstance(t2[name][i], str) and np.isnan(t2[name][i])

)

assert not isinstance(t2[name][i], str) and np.isnan(t2[name][i])

See discussion; I don't think we want to use npt.assert_ at all after that.

eerovaher

I've commented two uses of np.testing.assert_equal(), but analogous comments could be made throughout.

eerovaher · 2024-01-15T16:06:21Z

    """
-    assert_equal(len(t1), len(t2))
-    assert_equal(t1.colnames, t2.colnames)
+    npt.assert_equal(len(t1), len(t2))


Here npt.assert_equal() is being used to check lengths of lists. Compare the tracebacks:

============================================== FAILURES =============================================== __________________________________________ test_example_good __________________________________________ def test_example_good(): > assert len(list1) == len(list2) E assert 2 == 3 E + where 2 = len([1, 2]) E + and 3 = len([1, 2, 3]) example.py:8: AssertionError __________________________________________ test_example_bad ___________________________________________ def test_example_bad(): > np.testing.assert_equal(len(list1), len(list2)) E AssertionError: E Items are not equal: E ACTUAL: 2 E DESIRED: 3 example.py:11: AssertionError

eerovaher · 2024-01-15T16:10:04Z

-    assert_equal(len(t1), len(t2))
-    assert_equal(t1.colnames, t2.colnames)
+    npt.assert_equal(len(t1), len(t2))
+    npt.assert_equal(t1.colnames, t2.colnames)


Here npt.assert_equal() is being used to check columns of tables. Compare the tracebacks:

============================================== FAILURES =============================================== __________________________________________ test_example_good __________________________________________ def test_example_good(): > assert t1.colnames == t2.colnames E AssertionError: assert ['a', 'b', 'c'] == ['a', 'c'] E At index 1 diff: 'b' != 'c' E Left contains one more item: 'c' E Use -v to get more diff example.py:11: AssertionError __________________________________________ test_example_bad ___________________________________________ def test_example_bad(): > np.testing.assert_equal(t1.colnames, t2.colnames) E AssertionError: E Items are not equal: E ACTUAL: 3 E DESIRED: 2 example.py:14: AssertionError

dhomeier · 2024-01-15T16:48:52Z

Those are scalar/string comparisons. I did not expect the older helper functions would even have come into play there, but it looks like originally they were substitutes for unittest functions. I agree in those cases it makes no sense to bring numpy.testing in at all, so they will all have to be reviewed case by case.

dhomeier

Actually it seems the majority of equals are just comparing scalars or simple strings; so it might be better to default to assert first and then search for array-like and structured objects where to better stick with assert_equal.

dhomeier · 2024-01-15T17:07:20Z

+    npt.assert_equal(t1.colnames, t2.colnames)
    if check_meta:
-        assert_equal(t1.meta, t2.meta)
+        npt.assert_equal(t1.meta, t2.meta)


This is a bit trickier, as meta is neither a sequence nor a scalar, but typically a dict-like structure.
But here the numpy function should still provide better diagnostics:

>>> assert t1.meta == t2.meta AssertionError >>> assert_equal(t1.meta, t2.meta) AssertionError: Items are not equal: key='value' key='CLIPRANGE' key='keywords' ACTUAL: '2.5' DESIRED: '2.0'

The tracebacks the CPython interpreter produces can be very different from the tracebacks pytest produces:

============================================== FAILURES =============================================== __________________________________________ test_example_good __________________________________________ def test_example_good(): > assert t1.meta == t2.meta E AssertionError: assert {'CLIPRANGE':... 'value': 2.5} == {'CLIPRANGE':... 'value': 2.0} E Omitting 2 identical items, use -vv to show E Differing items: E {'value': 2.5} != {'value': 2.0} E Use -v to get more diff example.py:11: AssertionError __________________________________________ test_example_bad ___________________________________________ def test_example_bad(): > np.testing.assert_equal(t1.meta, t2.meta) E AssertionError: E Items are not equal: E key='value' E E ACTUAL: 2.5 E DESIRED: 2.0 example.py:15: AssertionError

Yes, the pytest version might be a bit more useful here still. Would you suggest to leave numpy's assert_equal to array-like objects only and use assert ...== for everything else?

When in doubt, make the test fail and see what the pytest traceback looks like. But for this pull request the reasonable thing to do would be to replace assert_equal() from commons.py with assert ... == ..., not np.testing.assert_equal(). commons.assert_equal(x, y) is basically an alias for assert x == y anyways, so that replacement will not make any potential tracebacks worse.

@dhomeier Should I start working on replacing the npt.assert_equal back to assert x == y.

We have discussed in the meantime that npt is not really a standard alias used by astropy, so

those imports should be changed to numpy.testing import assert_allclose, assert_equal in general

for comparing anything that is not an array-like collection of numerical values (i.e. basically anything that can be converted to a standard numerical-dtype ndarray), per the suggestions above, replace assert_equal with assert x == y.
Thanks!

Sure, will start my work as mentioned

Just to clarify, we want

assert_equal(arr_x, arr_y) assert obj_x == obj_y

… assert . Signed-off-by: Harsh-pandya <[email protected]>

…equals

…the marked TODOs. Signed-off-by: Harsh-pandya <[email protected]>

eerovaher · 2024-01-30T21:52:59Z

-    assert_true((data["a"].mask == [False, True]).all())
-    assert_true((data["a"] == [1, 1]).all())
-    assert_true((data["b"].mask == [False, True]).all())
-    assert_true((data["b"] == [2, 1]).all())
+    assert (data["a"].mask == [False, True]).all()
+    assert (data["a"] == [1, 1]).all()
+    assert (data["b"].mask == [False, True]).all()
+    assert (data["b"] == [2, 1]).all()


In case of an error we would get a better traceback with numpy.testing.assert_array_equal(), but the current patch would not make the traceback any worse than it already is. I'll therefore leave it to the sub-package maintainers to decide if the checks should be further modified in this pull request or if there should be a separate follow-up.

I'm highlighting this only here, but there are more analogous checks elsewhere.

Signed-off-by: Harsh-pandya <[email protected]>

Harsh-pandya · 2024-02-05T16:26:09Z

Hello, @dhomeier a gentle reminder for a review. Thank you for your time.

dhomeier · 2024-02-06T21:53:31Z

@@ -223,7 +218,7 @@ def test_read_all_files(fast_reader, path_format, home_is_data):
            table = ascii.read(testfile["name"], **test_opts)
            assert_equal(table.dtype.names, testfile["cols"])


Suggested change

assert_equal(table.dtype.names, testfile["cols"])

assert table.dtype.names == testfile["cols"]

These are tuples of strings, so better compared with the standard assert

dhomeier · 2024-02-06T21:54:31Z

@@ -253,7 +248,7 @@ def test_read_all_files_via_table(fast_reader, path_format, home_is_data):
            table = Table.read(testfile["name"], format=format, **test_opts)
            assert_equal(table.dtype.names, testfile["cols"])


Suggested change

assert_equal(table.dtype.names, testfile["cols"])

assert table.dtype.names == testfile["cols"]

as above

dhomeier · 2024-02-06T21:58:16Z

@@ -448,7 +443,7 @@ def process_lines(lines):
    reader.inputter.process_lines = process_lines
    data = reader.read("data/bars_at_ends.txt")
    assert_equal(data.dtype.names, ("obsid", "redshift", "X", "Y", "object", "rad"))


Suggested change

assert_equal(data.dtype.names, ("obsid", "redshift", "X", "Y", "object", "rad"))

assert data.dtype.names == ("obsid", "redshift", "X", "Y", "object", "rad")

dhomeier · 2024-02-06T22:30:00Z

+    assert (data["a"].mask == [False, True]).all()
+    assert (data["a"] == [1, 1]).all()
+    assert (data["b"].mask == [False, True]).all()
+    assert (data["b"] == [2, 1]).all()


Suggested change

assert (data["a"].mask == [False, True]).all()

assert (data["a"] == [1, 1]).all()

assert (data["b"].mask == [False, True]).all()

assert (data["b"] == [2, 1]).all()

assert_equal(data["a"].mask, [False, True])

assert_equal(data["a"], [1, 1])

assert_equal(data["b"].mask, [False, True])

assert_equal(data["b"], [2, 1])

I agree the numpy.testing function provides rather better diagnostics here even though the arrays are small.
This applies to all the assert (...).all() checks here and below.
In contrast, all the assert_equal uses above this line (basically all comparisons of some dtype.names are comparing tuples of non-numeric objects and should use assert == – not just those in the suggestions.

dhomeier · 2024-02-06T22:44:22Z

@@ -29,9 +28,9 @@ def test_read_normal():
    reader = ascii.get_reader(reader_cls=ascii.RST)
    dat = reader.read(table)
    assert_equal(dat.colnames, ["Col1", "Col2"])


Suggested change

assert_equal(dat.colnames, ["Col1", "Col2"])

assert dat.colnames == ["Col1", "Col2"]

Here as well, all the "names" comparisons are better done this way

neutrinoceros · 2024-02-26T13:32:07Z

 import numpy as np
 import pytest
 from numpy import ma
+from numpy.testing import assert_allclose, assert_equal


This looks half-finished. As you saw, we can just inline assert_equal instead of replacing it with numpy.testing.assert_equal. A couple call sites seem to remain, let's smoke them out !

Suggested change

from numpy.testing import assert_allclose, assert_equal

from numpy.testing import assert_allclose

This looks half-finished. As you saw, we can just inline assert_equal instead of replacing it with numpy.testing.assert_equal. A couple call sites seem to remain, let's smoke them out !

@neutrinoceros there has been an ongoing discussion from
#15839 (comment), #15839 (comment) and following about when to better use simple assert vs. Numpy's assert_equal on array-like operands. I am afraid there is no uncontroversial golden path where to use what, but my last set of comments and suggestion was trying to find a reasonable balance of using both options. Do you think assert x == y should be always preferred even on numerical ndarrays?

Oh, sorry I missed it !

Do you think assert x == y should be always preferred even on numerical ndarrays?

no ! I was trying to be strictly conservative in my review, but I agree that this pattern is best avoided for ndarrays !

neutrinoceros · 2024-02-26T13:35:49Z

    """
-    assert_equal(len(t1), len(t2))
+    assert len(t1) == len(t2)
    assert_equal(t1.colnames, t2.colnames)


Suggested change

assert_equal(t1.colnames, t2.colnames)

assert t1.colnames == t2.colnames

there's another one on line 1136

neutrinoceros · 2024-02-26T13:39:23Z


 import numpy as np
 import pytest
+from numpy.testing import assert_allclose, assert_equal


There are still 16 calls to assert_equal in this file to clean up (some of them already pointed out by @dhomeier)

Suggested change

from numpy.testing import assert_allclose, assert_equal

from numpy.testing import assert_allclose

neutrinoceros · 2024-02-26T13:41:36Z

 from io import StringIO

 import numpy as np
+from numpy.testing import assert_allclose, assert_equal


7 occurrences left to clean up here

Suggested change

from numpy.testing import assert_allclose, assert_equal

from numpy.testing import assert_allclose

dhomeier · 2024-04-04T14:14:03Z

@Harsh-pandya are you still available to finish this effort?

github-actions · 2024-06-29T05:40:49Z

Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then.

In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary.

If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock.

If you believe I commented on this pull request incorrectly, please report this here.

Harsh-pandya · 2024-06-30T16:06:00Z

Hello @dhomeier , Sorry for ghosting on this PR. I won't be able to continue on this PR. Thank you for your time and feedback on the PR.

pllim · 2024-07-01T16:57:41Z

There are already conflicts. And #16644 is not going to make the conflicts smaller. So closing without merge. Thanks anyway!

dhomeier · 2024-07-02T00:04:11Z

Thank you still for your contribution, @Harsh-pandya, it has sparked a fruitful discussion!

Refactor(io/tests): Replaced the usage of function called asset_equal…

9f675ac

… with np.testing.assert_equal Signed-off-by: Harsh-pandya <[email protected]>

github-actions Bot added the io.ascii label Jan 10, 2024

github-actions Bot reviewed Jan 10, 2024

View reviewed changes

Harsh-pandya added 4 commits January 9, 2024 19:24

Refactor(io/tests): Black formatting

b05a688

Signed-off-by: Harsh-pandya <[email protected]>

Refactor(io/tests): Replaced the usage of function called asset_true …

5b77e8c

…with np.testing.assert_equal Signed-off-by: Harsh-pandya <[email protected]>

Refactor(io/tests): Replaced the usage of function called asset_almos…

c611ecf

…t_equal with np.testing.assert_allclose Signed-off-by: Harsh-pandya <[email protected]>

Refactor(io/tests): Black Formatting

778c558

Signed-off-by: Harsh-pandya <[email protected]>

Harsh-pandya marked this pull request as ready for review January 10, 2024 04:18

Harsh-pandya requested review from dhomeier and taldcroft as code owners January 10, 2024 04:18

neutrinoceros reviewed Jan 10, 2024

View reviewed changes

dhomeier reviewed Jan 10, 2024

View reviewed changes

pllim added this to the v6.1.0 milestone Jan 10, 2024

pllim requested a review from eerovaher January 10, 2024 15:03

pllim added testing Refactoring no-changelog-entry-needed labels Jan 10, 2024

Refactor(io/tests): Requested changes on the code style of using impo…

eb5d6d9

…rts for numpy testing package. Also removed the unused import in common.py file. Signed-off-by: Harsh-pandya <[email protected]>

dhomeier requested changes Jan 10, 2024

View reviewed changes

eerovaher reviewed Jan 15, 2024

View reviewed changes

dhomeier requested changes Jan 15, 2024

View reviewed changes

dhomeier mentioned this pull request Jan 17, 2024

Ruff violation icn001 fix #15899

Merged

1 task

Harsh-pandya and others added 3 commits January 27, 2024 19:24

fix(io/tests): Requested changes on the usages of npt.asset_equal and…

35ea821

… assert . Signed-off-by: Harsh-pandya <[email protected]>

Merge branch 'astropy:main' into refactor_removed_the_usage_of_asset_…

0109f6d

…equals

fix(io/tests): Fixed the import format in test_cds.py. Also ,removed …

17ec69c

…the marked TODOs. Signed-off-by: Harsh-pandya <[email protected]>

Harsh-pandya requested a review from dhomeier January 29, 2024 04:39

eerovaher reviewed Jan 30, 2024

View reviewed changes

Harsh-pandya added 2 commits January 30, 2024 21:05

fix(io/tests): Fixed the formatting issue.

a9de058

Signed-off-by: Harsh-pandya <[email protected]>

fix(io/tests): Fixed the formatting issue in test_c_reader

01a4f11

Signed-off-by: Harsh-pandya <[email protected]>

dhomeier reviewed Feb 6, 2024

View reviewed changes

dhomeier mentioned this pull request Feb 21, 2024

TST: follow numpy/pytest traceback conventions in simple assert_* test helper functions #16080

Merged

9 of 13 tasks

neutrinoceros reviewed Feb 26, 2024

View reviewed changes

neutrinoceros mentioned this pull request Apr 4, 2024

Bugfix for issue 15782: Remove needless functions from an io.ascii test helper file #16266

Closed

1 task

astrofrog modified the milestones: v6.1.0, v7.0.0 Apr 4, 2024

pllim mentioned this pull request May 6, 2024

Removed needless functions from an io.ascii test helper file #15782 #16383

Closed

4 tasks

github-actions Bot added the Close? Tell stale bot that this issue/PR is stale label Jun 29, 2024

pllim closed this Jul 1, 2024

		@@ -223,7 +218,7 @@ def test_read_all_files(fast_reader, path_format, home_is_data):
		table = ascii.read(testfile["name"], **test_opts)
		assert_equal(table.dtype.names, testfile["cols"])

	assert_equal(table.dtype.names, testfile["cols"])
	assert table.dtype.names == testfile["cols"]

		@@ -253,7 +248,7 @@ def test_read_all_files_via_table(fast_reader, path_format, home_is_data):
		table = Table.read(testfile["name"], format=format, **test_opts)
		assert_equal(table.dtype.names, testfile["cols"])

	assert_equal(data.dtype.names, ("obsid", "redshift", "X", "Y", "object", "rad"))
	assert data.dtype.names == ("obsid", "redshift", "X", "Y", "object", "rad")

	assert_equal(dat.colnames, ["Col1", "Col2"])
	assert dat.colnames == ["Col1", "Col2"]

	from numpy.testing import assert_allclose, assert_equal
	from numpy.testing import assert_allclose

	assert_equal(t1.colnames, t2.colnames)
	assert t1.colnames == t2.colnames

Conversation

Harsh-pandya commented Jan 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

github-actions Bot commented Jan 10, 2024 • edited by dhomeier Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jan 10, 2024

Uh oh!

Harsh-pandya commented Jan 10, 2024

Uh oh!

neutrinoceros left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhomeier commented Jan 10, 2024

Uh oh!

dhomeier commented Jan 10, 2024

Uh oh!

dhomeier commented Jan 10, 2024

Uh oh!

pllim commented Jan 10, 2024

Uh oh!

dhomeier commented Jan 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pllim commented Jan 10, 2024

Uh oh!

eerovaher commented Jan 10, 2024

Uh oh!

dhomeier commented Jan 10, 2024

Uh oh!

dhomeier left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eerovaher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhomeier commented Jan 15, 2024

Uh oh!

dhomeier left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Harsh-pandya commented Feb 5, 2024

Uh oh!

Harsh-pandya commented Jan 10, 2024 •

edited

Loading

github-actions Bot commented Jan 10, 2024 •

edited by dhomeier

Loading

dhomeier commented Jan 10, 2024 •

edited

Loading