ENH: inline yt.funcs.is_sequence

[neutrinoceros]

PR Summary

This is in support to YTEP 0038, and more broadly in support to better typing in yt.
It is a follow up to #2893, in which I renamed has_len into is_sequence based on a misconception
I was having about the word "sequence" in Python.

I encourage reviewers to read this short page https://docs.python.org/3/library/collections.abc.html

So, the main reason this function needs to be discouraged is that its name is misleading. It is not equivalent to the following implementation

from collections.abc import Sequence
def is_sequence(obj):
    # check that `obj` has __getitem__, __len__, __reversed__ ...
    return isinstance(obj, Sequence)

On the other hand, it is equivalent to

from collections.abc import Sized
def is_sequence(obj):
    # check that obj has __len__
    return isinstance(obj, Sized)

and because this implementation is try-free as well as simpler, I replaced the current implem with it.

Now, since it is apparent that it can now be inlined at the same cost (one import), it seems reasonable to drop its usage internally, but we can still keep it for now, to avoid breaking downstream applications.

In many places where it is used, checking that a given object knows the __len__ protocol isn't exactly the appropriate thing to do. Sometimes we really want to check that objets are instances of collections.abc.Sequence or collections.abc.Collection. However, to avoid breaking anything by changing a lot of code at once, I stopped at the inlining step, except in one or two obvious cases, which I will highlight here with comments.

It is worth noting that np.ndarray objects are not considered as collections.abc.Sequence, because they don't implement the __reversed__ protocol. See https://docs.python.org/dev/glossary.html#term-sequence for more detail

PR Checklist

• [N/A] New features are documented, with docstrings and narrative docs
• [N/A] Adds a test for any bugs fixed. Adds tests for new features.

[neutrinoceros]

This is one of the few cases that I corrected the logic instead of producing exactly equivalent code

[neutrinoceros]

I added a sensible check here

[matthewturk]

Can you remind me if this has or had any impact on our usage of ensure_list to make sure that field lists are in fact lists of fields?

[neutrinoceros]

@matthewturk ensure_list was removed in #2893
The present PR is intended to have no impact on anything, besides the two (extremely minor) corrections highlighted above.
It is only about avoiding to entertain an incorrect notion of what "sequences" mean in Python, and make room to later use isinstance(..., Sequence) where relevant.

[neutrinoceros]

The GH workflow failures seem to be due to a change upstream on MacOs + home-brew + proj + gets + Python 3.9.7... So fixing this is out of scope here. However, the failures on Jenkins are real, so I'll make this a draft for now.

[neutrinoceros]

This allowed me to discover a bug in unyt yt-project/unyt#201
though this problem is blocking for the current PR so I'll keep it as a draft until it is resolved upstream.

[neutrinoceros]

Turns out the bug isn't in unyt, but in numpy. I think this PR is doomed because numpy arrays have weird behaviours and don't seem to play well with collections.abc. Down the line these problems completely break what I was trying to do here

See numpy/numpy#19833, and a related, long standing issue numpy/numpy#2776

I'll open another PR to try and reflect this knowledge better in our code base.