geary does hard typechecking of the weights object instead of ducktyping

[ljwolf]

In line 103, we simply disbar folks from passing a spatial weights matrix, even if it's API-compatible and can be used in the function. This means that, for instance, we can't pass a weights matrix from libpysal into pysal.esda.geary.Geary, since (post-conversion) this will demand weights from pysal itself. This happens in reverse for weights from pysal being sent to esda.geary.Geary.

I understand the interest in giving user-friendly errors in case they pass the wrong things to the wrong arguments, but I think that more ducktyping would help our library be quite a bit more flexible without demanding users either keep to the sub- or meta-packages.

[sjsrey]

Good catch.

I agree that ducktyping these type of out-of-date conventions (now that we have refactored the library) is the way to go.

[sjsrey]

Is this still an issue, since now we import form libpysal to check the parameter class?

[ljwolf]

yes, it is.

if you install esda for advanced cutting/edge functionality, but use pysal weights constructors, you're not able to use geary anymore.

I really feel we need to trust ducktyping and not typecheck on the input of w.

[ljwolf]

We could even write an as_weights() function that:

• checks if the w looks like an existing libpysal/pysal w and passes through
• checks if the w is a sparse matrix or a numpy dense matrix, casts that to a weights
• checks if the w is a networkx object, and then converts that using weights.from_networkx