BUG: Enable Series.equals to compare numpy arrays to scalars
State: closed

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


Labels:
name: Bug
name: Numeric Operations
description: Arithmetic, Comparison, and Logical operations

Comments:
How do we test functions in the _libs directory, or do we only test them indirectly? Since they don't have a directory in the test directory
Bit stuck here. Two tests in the CI keep failing due to a JSONArray being used in `pandas\tests\extension\base\interface.py` and `pandas\tests\extension\base\casting.py`, but locally pytest does not find these tests.
> Bit stuck here. Two tests in the CI keep failing due to a JSONArray being used in `pandas\tests\extension\base\interface.py` and `pandas\tests\extension\base\casting.py`, but locally pytest does not find these tests.

@avinashpancham I believe the tests you're looking for are in pandas/tests/extension/json/test_json.py (the files you mention are defining base testing classes from which others inherit)
This fix solves the problem described in the PR, but I found that ValueErrors are still thrown when different data types, such as dictionaries, are provided. Will work on that.

```
import pandas as pd
import numpy as np

arr = np.array([1, 2])
s1 = pd.Series([arr, arr])
s2 = s1.copy()

s1[1] = 9
s1.equals(s2) # Works

s1[1] = {"a": 1}
s1.equals(s2) # This throws a ValueError

```
@dsaxton Thanks for the explanation, that helped me with testing it locally
@jreback ran entire asv suite, see the top 10 below. It was ofc expected to be slower, but what would be acceptable? If necessary I can also share the complete list.

       before           after         ratio
     [8c7efd1c]       [bfb36ed4]
     <master>         <gh35267>
+        25.9±2ms         48.8±3ms     1.88  frame_methods.Equals.time_frame_nonunique_equal
+        26.6±2ms         48.6±3ms     1.83  frame_methods.Equals.time_frame_nonunique_unequal
+       754±200ns       1.25±0.7μs     1.66  index_cached_properties.IndexCache.time_inferred_type('Float64Index')
+        36.5±3ms         57.7±3ms     1.58  frame_methods.Equals.time_frame_object_unequal
+        47.4±2ms         68.2±4ms     1.44  frame_methods.Equals.time_frame_object_equal
+        19.8±3ms         27.9±3ms     1.41  index_object.SetOperations.time_operation('strings', 'symmetric_difference')
+     2.48±0.06ms       3.35±0.2ms     1.35  stat_ops.SeriesMultiIndexOps.time_op(0, 'sem')
+        83.8±1ms          112±8ms     1.34  rolling.ExpandingMethods.time_expanding('DataFrame', 'int', 'median')
+     1.84±0.03ms       2.45±0.2ms     1.33  stat_ops.SeriesMultiIndexOps.time_op(0, 'var')
+      2.83±0.6μs         3.69±2μs     1.31  index_cached_properties.IndexCache.time_engine('UInt64Index')


The running of the entire asv suite took close to 8 hours on my laptop. The [docs](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#running-the-performance-test-suite) state: "Running the full test suite can take up to one hour and use up to 3GB of RAM". 

Did I do something wrong, cause this is a significant difference, else we should give a more realistic estimate in the docs.
> The running of the entire asv suite took close to 8 hours on my laptop. The [docs](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#running-the-performance-test-suite) state: "Running the full test suite can take up to one hour and use up to 3GB of RAM".
> 
> Did I do something wrong, cause this is a significant difference, else we should give a more realistic estimate in the docs.

docs are likely out of data and the suite is now *much* bigger.
hmm these perf numbers are a big change. can you run the biggest ones *again*; sometimes the suite is flaky.
> > The running of the entire asv suite took close to 8 hours on my laptop. The [docs](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#running-the-performance-test-suite) state: "Running the full test suite can take up to one hour and use up to 3GB of RAM".
> > Did I do something wrong, cause this is a significant difference, else we should give a more realistic estimate in the docs.
> 
> docs are likely out of data and the suite is now _much_ bigger.

Is it ok if I submit an issue to get this corrected in the docs? I can imagine that people wouldn't mind running tests on their laptop for 1h, but not for approx 8h. Then they would rather do it on another machine/server
> > > The running of the entire asv suite took close to 8 hours on my laptop. The [docs](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#running-the-performance-test-suite) state: "Running the full test suite can take up to one hour and use up to 3GB of RAM".
> 
> > > Did I do something wrong, cause this is a significant difference, else we should give a more realistic estimate in the docs.
> 
> > 
> 
> > docs are likely out of data and the suite is now _much_ bigger.
> 
> 
> 
> Is it ok if I submit an issue to get this corrected in the docs? I can imagine that people wouldn't mind running tests on their laptop for 1h, but not for approx 8h. Then they would rather do it on another machine/server

sure
`frame_methods.Equals` and `index_cached_properties.IndexCache` still show a perf decrease in the 2nd run, see below. Can look if there is another way to solve the bug while maintaining similar perf.

The others (`index_object.SetOperations`, `stat_ops.SeriesMultiIndexOps` and `rolling.ExpandingMethods`) did not have a perf decrease in the 2nd run.

       before           after         ratio
     [822dc6f9]       [e94db6db]
                      <gh35267>

+        23.9±1ms       46.8±0.3ms     1.96  frame_methods.Equals.time_frame_nonunique_unequal
+        32.6±2ms         60.7±6ms     1.86  frame_methods.Equals.time_frame_object_unequal
+        25.0±1ms       45.5±0.7ms     1.82  frame_methods.Equals.time_frame_nonunique_equal
+      37.9±0.7ms         62.8±2ms     1.66  frame_methods.Equals.time_frame_object_equal

+      1.04±0.2μs       1.73±0.9μs     1.66  index_cached_properties.IndexCache.time_is_all_dates('UInt64Index')
+      1.10±0.1μs       1.62±0.7μs     1.46  index_cached_properties.IndexCache.time_inferred_type('UInt64Index')
+      1.37±0.2μs       2.00±0.7μs     1.46  index_cached_properties.IndexCache.time_is_all_dates('TimedeltaIndex')
+      1.23±0.2μs       1.75±0.5μs     1.42  index_cached_properties.IndexCache.time_inferred_type('TimedeltaIndex')
+      4.06±0.6μs         5.74±2μs     1.41  index_cached_properties.IndexCache.time_engine('TimedeltaIndex')
+        814±90ns       1.09±0.4μs     1.34  index_cached_properties.IndexCache.time_inferred_type('Float64Index')
+      1.35±0.1μs       1.72±0.2μs     1.27  index_cached_properties.IndexCache.time_is_all_dates('MultiIndex')
+       828±200ns        986±300ns     1.19  index_cached_properties.IndexCache.time_is_all_dates('Float64Index')
+      2.91±0.3μs         3.44±1μs     1.18  index_cached_properties.IndexCache.time_engine('UInt64Index')
+      1.94±0.1μs       2.23±0.1μs     1.15  index_cached_properties.IndexCache.time_inferred_type('IntervalIndex')

@jbrockmendel WDYT
I think apocalyptic smoke makes weekends really productive.  will take a look
try with the cython is_list_like need to cimport it
`is_list_like` is defined in `lib.pyx`, so then I dont need to import it right?
thanks @avinashpancham very nice!