1

I'm writing an interface to matplotlib, which requires that lists of floats are treated as corresponding to a colour map, but other types of input are treated as specifying a particular colour.

To do this, I planned to use matplotlib.colors.colorConverter, which is an instance of a class that converts the other types of input to matplotlib RGBA colour tuples. However, it will also convert floats to a grayscale colour map. This conflicts with the existing functionality of the package I'm working on and I think that would be undesirable.

My question is: is it appropriate/Pythonic to use an isinstance() check prior to using colorConverter to make sure that I don't incorrectly handle lists of floats? Is there a better way that I haven't thought of?

I've read that I should generally code to an interface, but in this case, the interface has functionality that differs from what is required.

Kyle_S-C
  • 1,107
  • 1
  • 14
  • 31

2 Answers2

2

Why not write two separate functions, one that treats its input as a color map, and another that treats its input as a color? This would be the simplest way to deal with the problem, and would both avoid surprises, and leave you room to expand functionality in the future.

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662
2

It's a little subjective, but I'd say: in general it's a not a good idea, but here where you're distinguishing between a container and an instance of a class it is appropriate (especially when, say, those classes may themselves be iterable, like tuples or strings and doing it the duck-typing would get quite tricky).

Aside: coding to an interface is generally recommended, but it's far more applicable to the Java-style static languages than Python, where interfaces don't really exist, unless you count abstract base classes and the abc module etc. (much deeper discussion in What's the Python version for “Code against an interface, not an object”?)

Hard to say without more details, but it sounds like you're closer to building a facade here than anything, and as such you should be free to use your own (neater / tighter / different) API, insulating users from your underlying implementation (Matplotlib).

Community
  • 1
  • 1
declension
  • 4,110
  • 22
  • 25
  • On the last bit, the issue is that I'm contributing to `networkx` and I haven't really contributed to a properly maintained package before. I am trying to keep my edits as minimal as possible, whilst adding the necessary functionality safely. – Kyle_S-C Nov 16 '14 at 16:11
  • OK.. in which case, I'd go for the type-checking, or just expose an alternative / additional method on your class, if that's an option (as also suggested by the other poster). Either way: unit tests... :) – declension Nov 16 '14 at 16:17
  • Yup, first thing I did after forking the project was finding out how `nose` worked. It's what they use for unit testing. – Kyle_S-C Nov 16 '14 at 16:17