Repository: networkx/networkx

Issue:
Why doesn't all_simple_paths check that a path exists?
Experimenting with a certain undirected graph, I stumbled upon an issue: `all_simple_path` was hanging and not yielding any paths. I checked if the path exists between the nodes I was interested in (`has_path`), and surprisingly it didn't. I would assume that the first thing the `all_simple_path` would do internally would be to check if any paths exist, and if not, return an empty generator right away. Why is this not the case?


Discussion:
I would assume that `all_simple_path` would *not* check for a path first, but rather be designed so that if no paths were found it would end the computation. Strange that it "hangs". According to its docs, it uses a version of DFS. I would hope that is just as fast for the first path found as the code behind `has_path`. It works very quickly for the non-connected graphs I just tried.  Can you give a small example?
Attaching a minimal example including a JSON describing the graph in question. What I forgot to mention is that I first exclude some edges using `subgraph_view` and then want to find paths in the filtered graph. The interesting part of the code is:

```
print("Is there a path from source to target?", nx.has_path(g_filtered, source, target))	# prints False
paths = nx.all_simple_paths(g_filtered, source=source, target=target, cutoff=10)
print("Path generator created")
for path in paths:
	print(path)		# There are no paths, but we're stuck in this loop
```

[networkx-issue-4518.zip](https://github.com/networkx/networkx/files/5770177/networkx-issue-4518.zip)

I can verify that this example takes longer than my patience allowed to compute simple paths even when they are valid nodes. And that was after I had eliminated the filter and only looked at the single component with 1114 nodes.  So, it is not surprising that the case when the target node is not in the connected component would take a long time (I added such a node and tried that too). 

So, here is the issue as I see it (please correct or embellish what I miss):
The `all_simple_paths` function is slow. If it is going to result in an error because the target is not connected to the source, we could avoid the slow calculation by checking for any path before finding all paths. That comes at the cost of checking for a path for valid source/target pairs.   Often users know whether the source and target have a path.

Should we automatically test for a path to save time for those who don't know? Or should be make the user check it before calling this function?

My (very weak) preference is to add a paragraph to the docs explaining that this function is slow and it might be very helpful to make sure there is a path between source and target before calling the function.  

Thoughts?
I would leave it up to the user. Since if they are unsure, they can just put a check around the call to `all_simple_paths` themselves.

Resolving patch:
diff --git a/networkx/algorithms/simple_paths.py b/networkx/algorithms/simple_paths.py
--- a/networkx/algorithms/simple_paths.py
+++ b/networkx/algorithms/simple_paths.py
@@ -207,6 +207,11 @@ def all_simple_paths(G, source, target, cutoff=None):
     number of simple paths in a graph can be very large, e.g. $O(n!)$ in
     the complete graph of order $n$.
 
+    This function does not check that a path exists between `source` and
+    `target`. For large graphs, this may result in very long runtimes.
+    Consider using `has_path` to check that a path exists between `source` and
+    `target` before calling this function on large graphs.
+
     References
     ----------
     .. [1] R. Sedgewick, "Algorithms in C, Part 5: Graph Algorithms",
@@ -214,7 +219,7 @@ def all_simple_paths(G, source, target, cutoff=None):
 
     See Also
     --------
-    all_shortest_paths, shortest_path
+    all_shortest_paths, shortest_path, has_path
 
     """
     if source not in G:


Test patch: