Simplify dihypergraph

[nwlandry]

This PR changes the internals of DiHypergraph so that it is more consistent with the other classes. This is an attempt to start addressing #379. This PR

• Replaces _node_in and _node_out with _node where _node[n] is of the form {"in": {tail}, "out": {head}}
• Replaces _edge_in and _edge_out with _edge where _edge[n] is of the form {"in": {}, "out": {}}
• Removes DiIDView since now we can simply inherit from IDView.
• Moves DiNodeView and DiEdgeView to views.py and deletes diviews.py
• Moves tests for directed views to test_views.py
• Removes unnecessary imports in the unit tests.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 98.68421% with 2 lines in your changes missing coverage. Please review.

Project coverage is 92.49%. Comparing base (c0f7593) to head (c4b8a73). Report is 1 commits behind head on main.

Files	Patch %	Lines
xgi/core/views.py	96.87%	2 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #541 +/- ## ========================================== + Coverage 92.35% 92.49% +0.14% ========================================== Files 60 59 -1 Lines 4499 4346 -153 ========================================== - Hits 4155 4020 -135 + Misses 344 326 -18 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[nwlandry]

@maximelucas - when do you think you will be able to take a look at this? Thanks!

[maximelucas]

I've had a look now, thanks! I left comments which are mostly questions for my own understanding.

The main one may be about about the choice between having H._node[node_id]["in"] and not H._nodes["in"][node_id]. I'm just wondering which one will be easier to generalise (don't know what I would choose). The first (current) option allows the call to H._[node_id] to be valid like before, but make it a bit more lengthy to access all "in" nodes. By the way, I'm just realising, what is an in-node again? 😛

If the API for the user is unchanged it's not needed, but otherwise we should document this somewhere.

[nwlandry]

I've had a look now, thanks! I left comments which are mostly questions for my own understanding.

The main one may be about about the choice between having H._node[node_id]["in"] and not H._nodes["in"][node_id]. I'm just wondering which one will be easier to generalise (don't know what I would choose). The first (current) option allows the call to H._[node_id] to be valid like before, but make it a bit more lengthy to access all "in" nodes. By the way, I'm just realising, what is an in-node again? 😛

If the API for the user is unchanged it's not needed, but otherwise we should document this somewhere.

Thanks for the review! I've thought quite a bit about your suggestion and I'd like to leave the structure (H._edge[e]["in] for example) as is for the following reasons:

• It seems natural for an edge ID to come with a list of all of its in- and out-connections
• The goal of this PR is to move us toward full inheritance and I think if we wanted to overload some algorithm definitions, it would be more natural for an edge ID to return a full edge, whether undirected or directed.

As far as your question goes, IMO it's most natural to think about it in the bipartite sense. If a node is specified as an input (in the tail) in a directed edge, that edge will add to its out-degree.

[maximelucas]

Thanks!