Add get_unspent() back to NetworkAPI
opened this issue · comments
Looks like we renamed get_unspent() to get_unspents() recently. Would be nice to have a wrapper function with the same name for backwards compatibility.
PR here: #41
Fantastic, thank you!
Looking into this more, this isn't such a big deal because it's changed anyways. Even with your change we can't call get_unspent(). We have to call NetworkAPI as a function.
This is what I used in walkingliberty and forgot about:
I'm sorry, I should have seen this sooner.
Here's what I ended up doing: https://github.com/teran-mckinney/bitcoinacceptor-python/commit/aedaeca2fd9dd317d2b283ee9b5d92c20b266f8b#diff-909255c8a6a005a80830665fa8d8f931R103
I think since this is non-trivial it's best to move forward with it as-is.
Thank you again, Josh!
Sounds good. It would be very messy to keep backwards compatibility from before the NetworkAPIs needed to be instantiated.
Yeah, that's for sure. I was thinking that just the function was renamed but that's certainly not all here.
Yes the big change is NetworkAPI instantiation. But other than that could just have an alias:
"self.get_unspent = self.get_unspents"
If that helps you clean up your code? Tbh changing the name from unspent --> unspents was in hindsight a bit of a mistake. I think I looked at the insightAPI naming convention and assumed that was the same... it also matches the PrivateKey naming. It looked out of place but should have been more careful.
Happy to support both names for better interoperability with bit/bitcash.
That isn't the only issue. With bit/bitcash, you call bit.network.NetworkAPI.get_unspent(address). With bitsv you have to call bitsv.network.NetworkAPI('main').get_unspents(address)
So even if it were just get_unspent(), you still have to treat NetworkAPI as a class or what not.
Yes, that's the big change.
It was a tough call (for this very reason ^^) but there were thought to be significant advantages to it after a decent period of discussion and therefore, on balance, we decided to go ahead.
Off the top of my head the reasons were stuff like:
It meant that instead of having 15 different functions (5 x 3 networks), we can just have 5. (Which allows deleting all of those in PrivateKey class too) --> more maintainable library etc.
Also means that production code (now that PrivateKey class works for all networks) can be tested on testnet or stn without modification (just propagate alternative parameter 'main', 'test', 'stn').
It also allows for overwriting of NetworkAPI class to a custom setup (e.g. maybe connect to a bitcoind node or ElectrumX aiorpcX setup..., RegTest etc) and this network_api object will be able to be passed into the PrivateKey class seamlessly as a parameter and just work the same.
This all snowballs into my next plan which is to have bip32 functionality inherit from bitsv.PrivateKey... (which is pretty important because the future of BSV will make heavy use of bip32)
Yup! I understand, it makes sense. It was a nice change on the whole, for sure.