MAINT: Renaming functions with a different name while dispatching

[Schefflera-Arboricola]

Reverting the change made in PR #32
The changes made in the above PR would let the user do something like nxp.tournament.is_strongly_connected(H) for functions with a different name in _dispachable decorator(ref PR’s first comment for more) but it breaks the way we currently create the get_info function and how we automatically generate the algorithms list in the README.md. Let me know what you think.

[Schefflera-Arboricola]

also, added this to make the user aware that this function uses a different name while dispatching.

[dschult]

I thought that users would never call this function directly -- that is, they would call the networkx function which in turn would call the appropriate function for them. Do I understand the public facing api correctly?

[Schefflera-Arboricola]

I don't think we are that strict about how someone "should" use a backend and a backend is also a package. So, I added this for someone who might want to call nx_parallel's implementation directly for their graph(like if the cost of dispatching through networkx to nx-parallel is too much for their case). But, as mentioned in the note added in README(in this PR) it's not the recommended way. If you think it's too much info to put in the main docs, then let me know, I can remove it and just keep(or maybe change a little) the first note in README.

[dschult]

OK... and I have a question: in the README file just after the paragraph describing this, the examples says:

 nx.approximate_all_pairs_node_connectivity(H)  # runs the parallel implementation in `approximation/connectivity`

But is this right? nx.approximate_all_pairs_node_connectivity(H) will raise due to the function not being found. In nx we call it as nx.approximation.all_pairs_node_connectivity(H)

I was thinking that the dispatcher calls the backend using the function nx_parallel.approximate_all_pairs_node_connectivity(H). but the user would still call it after importing networkx as nx.approximation.all_pairs_node_connectivity(H).

If I am right, we could allow both in the nx-parallel package (if you want to allow that) by including both routes to the name in the __init__.py files. But for now just having the longer name is Ok too. So I'm Ok with what is in this PR... But could you check the README.md example for how to call those functions?

[Schefflera-Arboricola]

Thank you very much for pointing this out!
fixed in #58

[dschult]

If you want to allow both ways to call the functions, we could do something like

Suggested change

	"approximate_all_pairs_node_connectivity",
	"approximate_all_pairs_node_connectivity",
	"all_pairs_node_connectivity",

and then below (after defining the longer named function) use

    all_pairs_node_connectivity = approximate_all_pairs_node_connectivity

But I'm fine with this PR as is. Which do you prefer?

[Schefflera-Arboricola]

while generating the get_info function we fetch all the functions in the nx_parallel package and then extract their docstrings... so having 2 all_pairs_node_connectivity functions in the package(one of them being in connectivity/connectivity(with docstring) and the other one being in approximation/connectivity(without docstring)) would probably result in an incorrect mapping between functions and the additional_docs. So, for now, I'd prefer the current implemented way, although this way does allow the user to use nx-parallel as an independent package, so I'd like to try and find if there's a better way to generate get_info. But, I think that's for another PR.

[dschult]

Sounds good!
I approve this PR