internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: networkx/networkx

Issue:
Missing edge label attribute in GEXFWriter
According to the [GEXF specification ](https://gephi.org/gexf/1.2draft/gexf-12draft-primer.pdf):

> Each edge can have a optional XML-attribute label, which is a string.

The [specification 1.2draft](https://github.com/gephi/gexf/blob/81ba4e7ccdc25631f836fc5caa4ed64ba5300379/specs/1.2draft/data.xsd#L73) defines this attribute as:
`<xs:attribute name="label" type="xs:token"/>`

The GEXF writer doesn't recognize this attribute correctly.
Instead it creates a new data attribute like:
```
		<attributes class="edge" mode="static">
			<attribute id="0" title="label" type="string"/>
		</attributes>
``` 


Discussion:

Resolving patch:
diff --git a/networkx/readwrite/gexf.py b/networkx/readwrite/gexf.py
--- a/networkx/readwrite/gexf.py
+++ b/networkx/readwrite/gexf.py
@@ -400,6 +400,11 @@ def edge_key_data(G):
         edges_element = Element("edges")
         for u, v, key, edge_data in edge_key_data(G):
             kw = {"id": str(key)}
+            try:
+                edge_label = edge_data.pop("label")
+                kw["label"] = str(edge_label)
+            except KeyError:
+                pass
             try:
                 edge_weight = edge_data.pop("weight")
                 kw["weight"] = str(edge_weight)


Test patch:
diff --git a/networkx/readwrite/tests/test_gexf.py b/networkx/readwrite/tests/test_gexf.py
--- a/networkx/readwrite/tests/test_gexf.py
+++ b/networkx/readwrite/tests/test_gexf.py
@@ -78,7 +78,7 @@ def setup_class(cls):
       </node>
     </nodes>
     <edges>
-      <edge id="0" source="0" target="1"/>
+      <edge id="0" source="0" target="1" label="foo"/>
       <edge id="1" source="0" target="2"/>
       <edge id="2" source="1" target="0"/>
       <edge id="3" source="2" target="1"/>
@@ -105,7 +105,7 @@ def setup_class(cls):
             indegree=1,
             frog=True,
         )
-        cls.attribute_graph.add_edge("0", "1", id="0")
+        cls.attribute_graph.add_edge("0", "1", id="0", label="foo")
         cls.attribute_graph.add_edge("0", "2", id="1")
         cls.attribute_graph.add_edge("1", "0", id="2")
         cls.attribute_graph.add_edge("2", "1", id="3")
@@ -573,7 +573,8 @@ def test_multigraph_with_missing_attributes(self):
         G = nx.MultiGraph()
         G.add_node(0, label="1", color="green")
         G.add_node(1, label="2", color="green")
-        G.add_edge(0, 1, id="0", weight=3, type="undirected", start=0, end=1)
+        G.add_edge(0, 1, id="0", wight=3, type="undirected", start=0, end=1)
+        G.add_edge(0, 1, id="1", label="foo", start=0, end=1)
         G.add_edge(0, 1)
         fh = io.BytesIO()
         nx.write_gexf(G, fh)
Repository: networkx/networkx

Issue:
Error message
The file networkx/generators/directed.py, line 262, the debug message is Wrong
Error message
The file networkx/generators/directed.py, line 262, the debug message is Wrong


Discussion:

Resolving patch:
diff --git a/networkx/generators/directed.py b/networkx/generators/directed.py
--- a/networkx/generators/directed.py
+++ b/networkx/generators/directed.py
@@ -255,11 +255,11 @@ def _choose_node(G, distribution, delta, psum):
         raise nx.NetworkXError("MultiDiGraph required in create_using")
 
     if alpha <= 0:
-        raise ValueError('alpha must be >= 0.')
+        raise ValueError('alpha must be > 0.')
     if beta <= 0:
-        raise ValueError('beta must be >= 0.')
+        raise ValueError('beta must be > 0.')
     if gamma <= 0:
-        raise ValueError('beta must be >= 0.')
+        raise ValueError('gamma must be > 0.')
 
     if abs(alpha + beta + gamma - 1.0) >= 1e-9:
         raise ValueError('alpha+beta+gamma must equal 1.')


Test patch:
Repository: networkx/networkx

Issue:
issues about the function 'preferential_attachment_graph' for bipartite networks
Hi, when using the function of  'preferential_attachment_graph'  to generate  a random bipartite network, how to set the probability 'p'?

I have checked the journal paper,  'Jean-Loup Guillaume and Matthieu Latapy, Bipartite structure of all complex networks, Inf. Process. Lett. 90, 2004, pg. 215-221', which gives a formula to calculate 'p'. But I wonder if the 'p' is the ratio of number of nodes to the sum of the sizes of the cliques, not 1 minus the ratio. 

Looking forward to your reply.


Discussion:
Hmmm..    Perhaps the best way to figure this out is to take an extreme case and see what ```p``` is.
For example, if ```p=1``` do you get the ratio or 1 minus the ratio?

The function requests ```p```, so you can choose to set it however you like. But I think you are seeking info about what impact that choice has on the structure.
Thank you for your reply. 

The author had made a mistake in this paper. I have found their another paper, 'Guillaume, J.L. and Latapy, M., 2006. Bipartite graphs as models of complex networks. Physica A: Statistical Mechanics and its Applications, 371(2), pp.795-813.', in which p equals the ratio.
I recommend that the reference paper be changed to the correct one, or the current one for this function may make people confused.

Thank you 
Maybe both references would be helpful.

Resolving patch:
diff --git a/networkx/algorithms/bipartite/generators.py b/networkx/algorithms/bipartite/generators.py
--- a/networkx/algorithms/bipartite/generators.py
+++ b/networkx/algorithms/bipartite/generators.py
@@ -380,7 +380,11 @@ def preferential_attachment_graph(aseq, p, create_using=None, seed=None):
 
     References
     ----------
-    .. [1] Jean-Loup Guillaume and Matthieu Latapy,
+    .. [1] Guillaume, J.L. and Latapy, M., 
+       Bipartite graphs as models of complex networks.
+       Physica A: Statistical Mechanics and its Applications,
+       2006, 371(2), pp.795-813.
+    .. [2] Jean-Loup Guillaume and Matthieu Latapy,
        Bipartite structure of all complex networks,
        Inf. Process. Lett. 90, 2004, pg. 215-221
        https://doi.org/10.1016/j.ipl.2004.03.007


Test patch:
Repository: networkx/networkx

Issue:
`draw_networkx` behaves differently when `node_size` is provided
If I call `draw_networkx` with something like

```
nx.draw_networkx(g, edgelist=[(0, 1, 0)])
```
that is, with the egelist a list of tuples of length 3, all works well. However, if I in addition pass a `node_size` argument that is an iterable, the behaviour changes and it expects edgelist to consist of tuples of length 2:
```
nx.draw_networkx(g, edgelist=[(0, 1, 0)], node_size=[10, 20])
```
```
/home/ruben/anaconda3/lib/python3.6/site-packages/networkx/drawing/nx_pylab.py in draw_networkx_edges(G, pos, edgelist, width, edge_color, style, alpha, arrowstyle, arrowsize, edge_cmap, edge_vmin, edge_vmax, ax, arrows, label, node_size, nodelist, node_shape, **kwds)
    659             shrink_target = 0  # space from  head to target
    660             if cb.iterable(node_size):  # many node sizes
--> 661                 src_node, dst_node = edgelist[i]
    662                 index_node = nodelist.index(dst_node)
    663                 marker_size = node_size[index_node]

ValueError: too many values to unpack (expected 2)
```
It may have got something to do with an assumption on graph type, my graph was of type `MultiDiGraph`.

This is not a big issue and easily worked around, but I thought I'd point out the inconsistent behaviour, if indeed it is.


Discussion:
Thank you for reporting this!

It is a bug. The offending line should allow edge 3-tuples from multigraphs by the code:

    src_node, dst_node = edgelist[i][:2]

We should check that section of code for other similar bugs and add a test that reveals this issue.

Resolving patch:
diff --git a/networkx/drawing/nx_pylab.py b/networkx/drawing/nx_pylab.py
--- a/networkx/drawing/nx_pylab.py
+++ b/networkx/drawing/nx_pylab.py
@@ -674,7 +674,7 @@ def to_marker_edge(marker_size, marker):
             shrink_source = 0  # space from source to tail
             shrink_target = 0  # space from  head to target
             if cb.iterable(node_size):  # many node sizes
-                src_node, dst_node = edgelist[i]
+                src_node, dst_node = edgelist[i][:2]
                 index_node = nodelist.index(dst_node)
                 marker_size = node_size[index_node]
                 shrink_target = to_marker_edge(marker_size, node_shape)


Test patch:
diff --git a/networkx/drawing/tests/test_pylab.py b/networkx/drawing/tests/test_pylab.py
--- a/networkx/drawing/tests/test_pylab.py
+++ b/networkx/drawing/tests/test_pylab.py
@@ -102,6 +102,12 @@ def test_empty_graph(self):
         G = nx.Graph()
         nx.draw(G)
 
+    def test_multigraph_edgelist_tuples(self):
+        # See Issue #3295
+        G = nx.path_graph(3, create_using=nx.MultiDiGraph)
+        nx.draw_networkx(G, edgelist=[(0, 1, 0)])
+        nx.draw_networkx(G, edgelist=[(0, 1, 0)], node_size=[10, 20])
+
     def test_alpha_iter(self):
         pos = nx.random_layout(self.G)
         # with fewer alpha elements than nodes
Repository: networkx/networkx

Issue:
2.3rc1 drops python 2.7 support in a minor version 
People using  `NetworkX~=2.2` as their version specifier to pip, but still on Python 2.7 will get this message now that 2.3rc1 is out:

```
NetworkX requires Python 3.5 or later (2.7 detected).
```

This happens with no changes to their code. 

Would dropping Python 2.7 support be enough of a change to necessitate a new major version of NetworkX?


Discussion:
Hmmm..   I suspect this is happening with many other packages. For example, pandas and numpy both planned to stop supporting python2. Neither plans to change the major release number -- numpy-1.17 will no longer support python2 and Pandas will have 0.24 be the last to support python2.

Maybe it will work for them because of people using ~=0.24.2 which is equivalent to >=0.24.2, == 0.24.*
Maybe we can do the same with people expected to use ~=2.2.0.  But we haven't been using 3 numbers for our releases.

Thoughts?
Going to `major.minor.patch` usually implies that that [Semantic Versioning](https://semver.org) is being used.  Is that what you're proposing?

Probably the simplest way to deal with this would be to make a note in the readme or docs about the versioning scheme and forwards/backwards compatibility expectations that a user should have. 
Would something like this work for you:
```
We don't use semantic versioning.  The first number indicates that we have
made a major API break (e.g., 1.x to 2.x), which has happened once and probably
won't happen again for some time.  The point releases are new versions and may
contain minor API breakage.  Usually, this happens after a one cycle deprecation
period.  API changes are documented here:
https://networkx.github.io/documentation/stable/release/index.html
```

Resolving patch:
diff --git a/networkx/release.py b/networkx/release.py
--- a/networkx/release.py
+++ b/networkx/release.py
@@ -214,6 +214,7 @@ def get_info(dynamic=True):
     'Programming Language :: Python :: 3.5',
     'Programming Language :: Python :: 3.6',
     'Programming Language :: Python :: 3.7',
+    'Programming Language :: Python :: 3 :: Only',
     'Topic :: Software Development :: Libraries :: Python Modules',
     'Topic :: Scientific/Engineering :: Bio-Informatics',
     'Topic :: Scientific/Engineering :: Information Analysis',


Test patch:
Repository: networkx/networkx

Issue:
dfs_preorder_nodes docstring says "edges" instead of "nodes"
https://github.com/networkx/networkx/blob/09c3da707d12aec42f3c0b2f91b60007bb436d37/networkx/algorithms/traversal/depth_first_search.py#L284


Discussion:

Resolving patch:
diff --git a/networkx/algorithms/traversal/depth_first_search.py b/networkx/algorithms/traversal/depth_first_search.py
--- a/networkx/algorithms/traversal/depth_first_search.py
+++ b/networkx/algorithms/traversal/depth_first_search.py
@@ -281,7 +281,7 @@ def dfs_preorder_nodes(G, source=None, depth_limit=None):
     G : NetworkX graph
 
     source : node, optional
-       Specify starting node for depth-first search and return edges in
+       Specify starting node for depth-first search and return nodes in
        the component reachable from source.
 
     depth_limit : int, optional (default=len(G))


Test patch:
Repository: networkx/networkx

Issue:
draw_networkx_nodes: Error doesn't show my mistakes exactly.
Hi, 

I passed nodelist to draw_networkx_nodes method as it needs.
But if I set nodelist as ndarray in numpy, it shows the following error.

```
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
```

The nodelist I passed is like as follows.

```
a = np.array([1, 2, 3, 4, 5)]
nx.draw_networkx_nodes(G, pos=pos, nodelist=a)
```
I'm sure G has each node in a, and pos is exactly what it needs.

I managed to solve this problem by transforming ndarray to list like this.

```
a = np.array([1, 2, 3, 4, 5)]
nx.draw_networkx_nodes(G, pos=pos, nodelist=a.tolist())
```

I believe that error confuses us, so we should either allow to pass ndarray or show a more accurate error.

Thank you for your consideration.




Discussion:
This looks like a bug. Thanks for the report!

Line 392 of ```nx_pylab.py``` should be changed from

    if not nodelist or len(nodelist) == 0: 
    # to something similar to this (untested)
    if len(nodelist) == 0 or not nodelist: 

Your workaround works in the meantime.

Resolving patch:
diff --git a/networkx/drawing/nx_pylab.py b/networkx/drawing/nx_pylab.py
--- a/networkx/drawing/nx_pylab.py
+++ b/networkx/drawing/nx_pylab.py
@@ -389,8 +389,8 @@ def draw_networkx_nodes(G, pos,
     if nodelist is None:
         nodelist = list(G)
 
-    if not nodelist or len(nodelist) == 0:  # empty nodelist, no drawing
-        return None
+    if len(nodelist) == 0:  # empty nodelist, no drawing
+        return
 
     try:
         xy = np.asarray([pos[v] for v in nodelist])


Test patch:
Repository: networkx/networkx

Issue:
[Typo][Doctring][graph.py][get_edge_data()]
The doc string of the `get_edge_details` fucntion of `graphy.py` seems to have a minor typo.
```
    def get_edge_data(self, u, v, default=None):
        """Returns the attribute dictionary associated with edge (u, v).
        This is identical to `G[u][v]` except the default is returned
        instead of an exception is the edge doesn't exist.
```
 **is** `the edge doesn't exist.` should be **if** `the edge doesn't exist.`
Line: https://github.com/networkx/networkx/blob/master/networkx/classes/graph.py#L1331


Discussion:
Thanks!

Resolving patch:
diff --git a/networkx/classes/graph.py b/networkx/classes/graph.py
--- a/networkx/classes/graph.py
+++ b/networkx/classes/graph.py
@@ -1328,7 +1328,7 @@ def get_edge_data(self, u, v, default=None):
         """Returns the attribute dictionary associated with edge (u, v).
 
         This is identical to `G[u][v]` except the default is returned
-        instead of an exception is the edge doesn't exist.
+        instead of an exception if the edge doesn't exist.
 
         Parameters
         ----------


Test patch:
Repository: networkx/networkx

Issue:
faulty gomory_hu method
Hi, 
it seems the implementation of gomory_hu is faulty: the computed tree is not necessarily a Gomory-Hu (cut) tree. Indeed, in the tree (bottom left) in the figure, the edge (2,3) indicates that {0,2} should give a smallest cut separating 2 from 3. The cut, however, contains four edges (unit weights) but the smallest cut, the edges incident with 2, has size 3. The tree at the bottom right should be a proper G-H tree.

![gh](https://user-images.githubusercontent.com/46501322/50855647-b4b8ca00-1388-11e9-83c0-8804b8b562d8.png)

The issue apparently stems from the fact that a couple of lines of the Gusfield algorithm have been omitted from the implementation in networkx. The lines that are missing are the last seven or so lines on page 152 in Gusfield's paper. I've attached a modified version of the gomory_hu method that should correct this (zipped). I've also attached a jupyter notebook that compares the current implementation with the fix (zipped). Note the weights computed by the nx.gomory_hu method seem okay -- it's only the tree that may be incorrect. 

Caveat: I was too lazy to check that Gusfield's algorithm actually works. 

Henning

[gomory-hu.zip](https://github.com/networkx/networkx/files/2738256/gomory-hu.zip)



Discussion:

Resolving patch:
diff --git a/networkx/algorithms/flow/gomory_hu.py b/networkx/algorithms/flow/gomory_hu.py
--- a/networkx/algorithms/flow/gomory_hu.py
+++ b/networkx/algorithms/flow/gomory_hu.py
@@ -164,7 +164,8 @@ def gomory_hu_tree(G, capacity='capacity', flow_func=None):
         target = tree[source]
         # compute minimum cut
         cut_value, partition = nx.minimum_cut(G, source, target,
-                                              capacity=capacity, flow_func=flow_func,
+                                              capacity=capacity,
+                                              flow_func=flow_func,
                                               residual=R)
         labels[(source, target)] = cut_value
         # Update the tree
@@ -172,9 +173,16 @@ def gomory_hu_tree(G, capacity='capacity', flow_func=None):
         for node in partition[0]:
             if node != source and node in tree and tree[node] == target:
                 tree[node] = source
-                labels[(node, source)] = labels.get((node, target), cut_value)
+                labels[node, source] = labels.get((node, target), cut_value)
+        #
+        if target != root and tree[target] in partition[0]:
+            labels[source, tree[target]] = labels[target, tree[target]]
+            labels[target, source] = cut_value
+            tree[source] = tree[target]
+            tree[target] = source
+
     # Build the tree
     T = nx.Graph()
     T.add_nodes_from(G)
-    T.add_weighted_edges_from(((u, v, labels[(u, v)]) for u, v in tree.items()))
+    T.add_weighted_edges_from(((u, v, labels[u, v]) for u, v in tree.items()))
     return T


Test patch:
Repository: networkx/networkx

Issue:
jit json import/export
I would consider the functions `jit_data` and `jit_graph` to be their inverses, so that
```
import networkx as nx
nx.jit_graph(nx.jit_data(nx.Graph()))
```
works.

Instead, it produces a TypeError (nx 2.2), because jit_data is a function `nx graph -> json string`, while jit_graph is a function `json object -> nx graph`, so that the correct program would be
```
import networkx as nx
import json
nx.jit_graph(json.loads(nx.jit_data(nx.Graph())))
```

This is documented, but in my view unexpected and incoherent behavior. I'm pretty new to networkx and are not familiar with your design philosophy, but see the options
* to add a clarifying note in the documentation OR
* return the json object in `jit_data` OR
* make use of the json.loads function in `jit_graph`.

What are your opinions on this?
I am willing to submit a PR (but probably it is just easier for you to make that oneline-commit, so that's also fine :))


Discussion:

Resolving patch:
diff --git a/networkx/readwrite/json_graph/jit.py b/networkx/readwrite/json_graph/jit.py
--- a/networkx/readwrite/json_graph/jit.py
+++ b/networkx/readwrite/json_graph/jit.py
@@ -60,6 +60,9 @@ def jit_graph(data, create_using=None):
         G = create_using
         G.clear()
 
+    if nx.utils.is_string_like(data):
+        data = json.loads(data)
+
     for node in data:
         G.add_node(node['id'], **node['data'])
         if node.get('adjacencies') is not None:
@@ -77,10 +80,10 @@ def jit_data(G, indent=None):
     G : NetworkX Graph
 
     indent: optional, default=None
-        If indent is a non-negative integer, then JSON array elements and object
-        members will be pretty-printed with that indent level. An indent level
-        of 0, or negative, will only insert newlines. None (the default) selects
-        the most compact representation.
+        If indent is a non-negative integer, then JSON array elements and
+        object members will be pretty-printed with that indent level.
+        An indent level of 0, or negative, will only insert newlines.
+        None (the default) selects the most compact representation.
 
     Returns
     -------


Test patch:
diff --git a/networkx/readwrite/json_graph/tests/test_jit.py b/networkx/readwrite/json_graph/tests/test_jit.py
--- a/networkx/readwrite/json_graph/tests/test_jit.py
+++ b/networkx/readwrite/json_graph/tests/test_jit.py
@@ -55,3 +55,10 @@ def test_jit_multi_directed(self):
         K.add_edge(1, 2)
         assert_false(nx.is_isomorphic(H, K))
         assert_true(nx.is_isomorphic(G, K))
+
+    def test_jit_round_trip(self):
+        G = nx.Graph()
+        d = nx.jit_data(G)
+        H = jit_graph(json.loads(d))
+        K = jit_graph(d)
+        assert_true(nx.is_isomorphic(H, K))
Repository: networkx/networkx

Issue:
`make_small_graph` may fail to return error when it gets a bad input
The following command was used in an answer on [stackoverflow](https://stackoverflow.com/a/56032840/2966723), and produces a very different result from desired:

    gr = {
        0: [4],
        1: [3],
        2: [2, 3, 4, 5],
        3: [1, 3],
        4: [3],
        5: [4]
    }
    G = nx.make_small_graph(gr)

But it isn't what they expected to happen:

    G.nodes()
    > NodeView((2, 3, 4, 5))
    G.edges()
    > EdgeView([])

Because `gr[0]`, `gr[1]`, and `gr[2]` are defined, no error message is returned.  The code then creates an empty graph with the nodes from `gr[2]`  (that is with `[2,3,4,5]`).  It then fails to add any edges because `gr[0]` isn't of the right form.

I think the easiest fix is to add an extra condition if `gr[0]` is not either `'edgelist'` or `'adjacencylist'` to return an error.



Discussion:

Resolving patch:
diff --git a/networkx/generators/small.py b/networkx/generators/small.py
--- a/networkx/generators/small.py
+++ b/networkx/generators/small.py
@@ -83,6 +83,10 @@ def make_small_graph(graph_description, create_using=None):
 
     Use the create_using argument to choose the graph class/type.
     """
+
+    if graph_description[0] not in ("adjacencylist", "edgelist"):
+        raise NetworkXError("ltype must be either adjacencylist or edgelist")
+
     ltype = graph_description[0]
     name = graph_description[1]
     n = graph_description[2]


Test patch:
diff --git a/networkx/generators/tests/test_small.py b/networkx/generators/tests/test_small.py
--- a/networkx/generators/tests/test_small.py
+++ b/networkx/generators/tests/test_small.py
@@ -16,10 +16,16 @@
 
 class TestGeneratorsSmall():
     def test_make_small_graph(self):
-        d = ["adjacencylist", "Bull Graph", 5, [[2, 3], [1, 3, 4], [1, 2, 5], [2], [3]]]
+        d = ["adjacencylist", "Bull Graph", 5, [[2, 3], [1, 3, 4], [1, 2, 5],
+                                                [2], [3]]]
         G = nx.make_small_graph(d)
         assert is_isomorphic(G, nx.bull_graph())
 
+        # Test small graph creation error with wrong ltype
+        d[0] = "erroneouslist"
+        pytest.raises(nx.NetworkXError, nx.make_small_graph,
+                      graph_description=d)
+
     def test__LCF_graph(self):
         # If n<=0, then return the null_graph
         G = nx.LCF_graph(-10, [1, 2], 100)