Skip to content

PathpyG.io API inconsistencies/problems #301

Open

Description

@M-Lampert

I think the current naming scheme of the pp.io module is somewhat inconsistent and confusing:

  • df_to_graph is misleading since it does not result in a "proper" graph because the node attributes are missing. The opposite is also the case, the function graph_to_df is in reality more something in the lines of edges_to_df.
  • There is a write_csv function but no read_csv function; instead, there are several read_csv_... functions - one for each class. Inside write_csv.
  • Hardcoding the column names to v and w seems very inflexible to me.

I propose the following changes:

  • Instead of df_to_graph, there should be a read_dataframe(edges: Optional[DataFrame], nodes: Optional[DataFrame]) function that takes two optional dataframes, one for edges and one for nodes. This should then also be made consistent with all other formats, e.g. read_csv(edges: Optional[str | Path], nodes: Optional[str | Path]). Ideally, these methods should automatically attempt to infer the class, i.e. simple or temporal graph, with an additional option to set the class specifically.
  • Instead of graph_to_df, we would then have a function write_dataframe(...) -> DataFrame, DataFrame that returns two dataframes by default, one for the nodes and one for the edges.
  • Additionally, there could be functions like edges_to_df and nodes_to_df which would split the functionality of write_dataframe into two parts.
  • For flexibility, all of these methods should have parameters like source_col, target_col and time_col that specify the name of the column that contains the source/target node and the timestamp.
  • PathData could either be handled separately or included into the above with an additional optional parameter read_csv(edges, nodes, paths).

Activity

  1. self-assigned this
    on Sep 22, 2026
  2. M-Lampert commented on Sep 22, 2026

    @M-Lampert
    ContributorAuthor

    @vineetbansal issue #250 and the corresponding draft PR #303 are related to this. Maybe you can merge my draft for the SQL integration into your branch if you are working on this and merge both together into dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions