Wiener index is a distance measure #6975
Conversation
There was a problem hiding this comment.
Unfortunately this is a backward incompatible change: any existing user code which accesses the wiener module will break. Therefore, in principle would require a warning cycle; i.e. raising a FutureWarning for access patterns like from networkx.wiener import wiener_index or nx.wiener.wiener_index1.
There are a few things that could be done here. If others agree that this reorganization is worth the churn, then we could go ahead with the warning introduction now. Another option would be to table this for a larger namespace cleanup akin to e.g. what scipy did. If we did that in NetworkX, then once that change went through (after a 2-release warning cycle) then moving the implementation either becomes moot (because the location of it's definition is private) or is non-breaking.
Footnotes
-
neither of these access patterns is recommended, but they are possible so there is likely code that depends on them. ↩
|
I didn't realise about those incompatibilities. Looking forward to hear your opinions about the suggested change. |
|
Personally, I'd vote to handle these types of refactors (i.e. moving where things are defined) wholistically rather than on a case-by-case basis. As you've noticed (cf. #7065), this is not the only instance where there may be an opportunity to refactor the module/package structure. I'd prefer to do so all at once rather than introduce individual warnings cycles for each instance. |
|
I'm fine with such a general overhaul rather than a case-by-case basis. It is a good idea to keep a list of all those suggested changes @rossbar ? |
|
Could we create an issue that tracks the different suggestions for refactoring? If/when that issue gets too long or disjoint, we could convert it into a NXEP with a file in |
ghost
closed this
ghost
deleted the
The Wiener index is actually a measure of distance.
So moved it from its own category to the Distance measures.