Skip to content

BUG: revert assert_numpy_array_equal to before c2ea8fb2 (accept non-ndarrays) #13355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

toobaz
Copy link
Member

@toobaz toobaz commented Jun 3, 2016

  • tests added / passed
  • passes git diff upstream/master | flake8 --diff

assert_numpy_array_equal's docstring is at odds with (and the existence of the obj argument clashes with) the fact that it's now strict on its arguments being ndrarrays.

There are practical reasons to allow other kinds of arguments.

On the other hand, I don't see any reason for being strict, but I assume @sinhrks 's PR had some rationale behind: so a possible solution is an argument ensure_ndarray=True which restores the previous behaviour when set to False.

@codecov-io
Copy link

Current coverage is 84.23%

Merging #13355 into master will increase coverage by <.01%

@@             master     #13355   diff @@
==========================================
  Files           138        138          
  Lines         50721      50725     +4   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          42723      42727     +4   
  Misses         7998       7998          
  Partials          0          0          

Powered by Codecov. Last updated by 0c6226c...53ad5b1

@sinhrks
Copy link
Member

sinhrks commented Jun 3, 2016

-1 to allow non-ndarray only for a single issue. How about add check_dtype arg?

@jreback
Copy link
Contributor

jreback commented Jun 3, 2016

you can't simply change the test procedure. The entire point is to make tests more strick. So pls change as to @sinhrks suggestion.

Ideally we would be extremely strict on everything. The better checking that we have on tests the less ambiguity and the less that slips thru. The original PR did a lot to correct this.

@jreback jreback added the Testing pandas testing functions or related to the test suite label Jun 3, 2016
@toobaz
Copy link
Member Author

toobaz commented Jun 3, 2016

We want strict tests, this is a function. Which I'm not "changing", except for noticing that recent changes made its behaviour incoherent with docstring and arguments.

So leaving aside general lectures on fundamentals of computation, @sinhrks what's your suggestion? There already is a check_dtype arg... are you saying check_dtype=False should mean "don't even verify whether it's a numpy array"?

(fine for me, but we loose the possibility of comparing numpy arrays of different dtypes by still ensuring they are numpy arrays)

@sinhrks
Copy link
Member

sinhrks commented Jun 4, 2016

Sorry, forget about check_dtype. I may not understand original discussion properly, can you show a test case which should be succeed in this case?

@toobaz
Copy link
Member Author

toobaz commented Jun 4, 2016

So, 4 options:

  1. the current behaviour:
assert_numpy_array_equal(array([1,2]), [1, 2], check_dtype=WHATEVER) #Fails
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_dtype=False) #Passes
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_dtype=True) #Fails
  1. the previous behaviour/current docstring/current PR:
assert_numpy_array_equal(array([1,2]), [1, 2], check_dtype=WHATEVER) #Passes
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_dtype=False) #Passes
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_dtype=True) #Fails
  1. my proposal (new argument check_ndarray, presumably defaulting to True):
assert_numpy_array_equal(array([1,2]), [1, 2], check_ndarray=False, check_dtype=WHATEVER) #Passes
assert_numpy_array_equal(array([1,2]), [1, 2], check_ndarray=True, check_dtype=WHATEVER) #Fails
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_ndarray=WHATEVER, check_dtype=False) #Passes
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_ndarray=WHATEVER, check_dtype=True) #Fails
  1. my interpretation of @sinhrks 's suggestion (making the existing check_dtype, which defaults to True, more strict):
assert_numpy_array_equal(array([1,2]), [1, 2], check_dtype=False) #Passes
assert_numpy_array_equal(array([1,2]), [1, 2], check_dtype=True) #Fails
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_dtype=False) #Passes
assert_numpy_array_equal(array([1,2]), array([1.0, 2]), check_dtype=True) #Fails

If we stick with 1), it probably makes more sense to write a new function assert_is_copy, which would work on non-ndarrays too (as I was previously doing in my other PR), than to add the check_same argument to assert_numpy_array_equal as I am doing now.

I personally don't have strong preferences, we should just be coherent.

@toobaz toobaz mentioned this pull request Jun 5, 2016
4 tasks
@sinhrks
Copy link
Member

sinhrks commented Jun 14, 2016

Closed by #13025, thx:)

@sinhrks sinhrks closed this Jun 14, 2016
@toobaz
Copy link
Member Author

toobaz commented Jun 14, 2016

@sinhrks : this is maybe closed by you implicitly stating "we like the current behaviour" (option 1), but certainly not by #13205 (see this comment ) ;-) Which is fine by the way, if this is what you intended.

@sinhrks
Copy link
Member

sinhrks commented Jun 14, 2016

Ah I misunderstood #13025 covers curent needs.

Personally I'm +1 for option 1, but reopen for feedback from others.

@sinhrks sinhrks reopened this Jun 14, 2016
@jreback
Copy link
Contributor

jreback commented Jun 14, 2016

yeah I think option 1 is fine, which is current behavior I think. @toobaz the cases you had worked around in #13205 look ok to me. If you find additional issues or think API needs changing, pls make a new issue (or we can discuss here).

@jreback jreback closed this Jun 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Testing pandas testing functions or related to the test suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants