Generally speaking, it’s good to have as much in the C core as possible. igraph’s philosophy so far has been to put as much into the C core as possible, much more so than a typical C library would. (See e.g. my request.)
But with attributes, things get a little more complicated.
Attribute storage is specific to each high-level interface. It has to be so in order to allow integrating igraph deeply into its host language (e.g. allow native datatypes to be used as attributes).
Graph union and difference by vertex names is the domain of high-level interfaces because it requires at least an equality comparison (
==) for attribute values, whose storage is interface-specific. Other similar operations may require (or may benefit from)
< or hashing too. This cannot be done for the host language’s datatypes from C.
There are two separate things discussed in that GitHub issue:
- Reading CSVs. @tamas makes a good point why reading CSV files should be left to other libraries, not igraph.
- Creating a graph from a “dataframe”. What “dataframe” means, and what the most natural way to convert to a graph is, are both specific to the host language. An easy way to go from a Pandas dataframe to a graph would be very useful, but this is again the domain of the Python interface, not the C core.
To sum up, personally I support moving as much as possible to the C core. But these two specific things cannot be moved to the C core in any reasonable way (except raw CSV reading, but there are good reasons not to do that in igraph).