search

pysal / esda

statistics and classes for exploratory spatial data analysis
https://pysal.org/esda
BSD 3-Clause "New" or "Revised" License
215 stars 55 forks source link

geary does hard typechecking of the weights object instead of ducktyping #45

Open ljwolf opened 5 years ago

ljwolf commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

ljwolf commented 5 years ago

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 commented 5 years ago

We could even write an as_weights() function that: