Implement subclasses of CCXT locked to one exchange

[macanudo527]

Actually this is an interesting idea: would it make sense to add variants (subclasses) of your CCXT converter that use a fixed exchange (one for Binance, one for Kraken, etc.)? The binance subclass would be exactly equivalent to the pair converter in this PR. Additionally, if we added a CCXT converter subclass for Coinbase, it should be equivalent to the HistoricCrypto plugin. Does that sound correct or am I missing something?

Originally posted by @eprbell in #60 (comment)

Implement subclasses or create a method of prioritizing one exchange's pricing data over another.

[macanudo527]

Is there a way to simply place two different instantiations of the same plugin in the pricing stack? So that we could just instantiate one CCXT plugin locked to Binance, and then another locked to Coinbase. I don't think we would need to put much in the subclass other than have a different class name.

Or is there an automagic way in Python to create generic subclasses dynamically?

[eprbell]

o

I think the best way is to have separate python files, one per exchange: each file would contain a (probably) trivial subclass of CCXT. Then the user can arrange them in their priority order of choice in the configuration.

[macanudo527]

I'm pretty sure this can simply be implemented by passing a param. I don't think a subclass is really needed. Or are subclasses preferred for clarity's sake?

[eprbell]

Yeah, I'm thinking classes would be both clearer to use and more in line with the rest of the design (one class per service, whether it's an exchange, a price provider, a wallet, etc.).

[macanudo527]

This should be resolved with the latest PR.