Some ideas on refactoring for ease of maintenance, extendability and compatibility with networkx.

[verginer]

The networkx project is, I think, a project which pathpy might look to be highly compatible with, since its users are among the most likely to use pathpy. To that end it would be useful to refactor the api to be in line with the PEP8 style guide as well as separating the algorithms working on the various objects from those objects (i.e. get_betweeness_preference for Paths becomes a function and not a method).

Here are a few daring proposals (just my opinion 😁) that in part would break backward compatibility 💥

• refactor variable names, methods and properties to PEP8 (e.g. getSequence() becomes sequence())
• move data structures (i.e. Paths, HigherOrderNetwork, MarkovSequence and TemporalNetwork) into a classes sub-module (i.e. a folder) (inspired by structure of networkx)
• move algorithms into an algorithms sumodules
  • this would allow more flexibility and transparency when adding or modifying algorithms later
  • by correctly loading them in the relevant __init__.py the additional level in the file hierachy would not be visible to the user.
  • This would mean that a user would call pathpy.betweenness_preference(paths_inst) instead of paths_inst.betweenness_preference() the latter behavior can still be maintained if desired
• Implement a helper functions to convert patphy objects to most adequate nx equivalent an vice versa
  • reduces the barrier to entry to users of nx
  • benefits from algorithm already implemented in nx
• Use the logging module in the python standard library instead of the current custom implementation (Log)
• Write documentation in sphinx style (so it can be compiled and viewed in https://readthedocs.org/

I have already implemented some of these changes and kept the functionality equal to the current pathpy implementation (thanks to unit tests) (see here).

Sorry for long post.

[IngoScholtes]

Hi Luca

These are great proposals which I am happy to incorporate.

I am currently working on an extended successor version pathpy 2.0, due for release this summer. For this, I think it'll be great to do the refactorings you propose. I will start thinking about this right away. I will also push a development branch of the next version soon, so we can start working on that.

Thanks a lot for your great suggestions and your support!