Apologies if this is a naive question, but I noticed that the ci/circleci: documentation job failed on my PR. I came across issue #8297 which mentions intermittent doc build failures (possibly related to the new iplotx example). Could you please confirm if this failure is related to my changes, or if it’s part of the ongoing issue? I just want to make sure I’m not overlooking something on my end.

There are indeed problems with NX's circleci setup at the moment. The root cause has not yet been chased down but for now it's safe to simply ignore the red-x's from circleci. Sorry for the inconvenience!

Got it — thanks a lot for clarifying!

Got it — thanks for the clarification!
I’ll update the docstring accordingly: de-emphasize the detailed explanation of the *View / *DataView types, and instead highlight the common usage convention (using .nodes / .edges for setting attributes and .nodes() / .edges() for querying).

I’ve made the suggested changes — de-emphasized the *View / *DataView type details,
emphasized the “attribute-like for setting, method-like for getting” convention,
and added a short multigraph note showing the key-handling difference.

I also placed the new subsection right after “Examining elements of a graph”,
since that’s the first place in the tutorial where both attribute and method forms appear in examples.
I thought it’d be a natural spot to explain the distinction,
but I’m happy to move it if you feel it belongs elsewhere.

I merged the MultiGraph initialization and the first list(MG.edges) call into a single code cell to avoid the stray output (1) that appeared in the rendered tutorial.

Before:

MG = nx.MultiGraph()
MG.add_edge(1, 2)   # key=0
MG.add_edge(1, 2)   # key=1

1

(Rendered output included an unintended 1 because add_edge returns the edge key.)

After:

MG = nx.MultiGraph()
MG.add_edge(1, 2)   # key=0
MG.add_edge(1, 2)   # key=1
list(MG.edges)

[(1, 2, 0), (1, 2, 1)]

Combining them in one cell ensures that the last executed expression is the intended example output (list(MG.edges)) rather than the return value of add_edge.
This keeps the rendered tutorial clean.

Thanks for the updates @Aka2210 - after reading through this and the previous discussion, the impression I was left with was this was a lot of nitty-gritty detail for the tutorial.

I've left a concrete suggestion in the inline review comments that IMO at least is a slightly higher-level look that flows with the tutorial. Now, it doesn't cover everything - in fact the lack of any explicit mention of views is intentional - but I think it may fit with the tutorial better, while some of the finer-grained detail could be added later/elsewhere, e.g. the documentation on view objects. WDYT?

Thanks again for the detailed explanation and suggested wording!

I’ve updated the tutorial section to match your “Access patterns” version and verified that the (attributes) link correctly points to the “Adding attributes to graphs, nodes, and edges” section in the tutorial.

I've also fixed the style issues noted in CI.
I agree that keeping the tutorial high-level and leaving out explicit discussion of views here makes sense.
Thanks for the guidance!