Python methods for corresponding Kraken API methods

[tasercake]

I think it would make things a lot easier if one could call API methods directly from an API() instance in Python rather than putting out using query_public() or query_private() each time. Having python methods would also help with code completion.

Has there been a decision to not include individual python methods for each API method?
If this is not the case, are there any plans to implement corresponding python methods anytime soon?

[veox]

You probably mean using k.balance() instead of k.query_public('Balance'), and the like?..

Please give examples of what you propose. No need to flesh out over the entire Kraken API method space. :)

---

Also, turning Kraken API methods into package API methods means we could have some long-absent methods that are present in Kraken's internal codebase, but not as external API methods - such as the "available balance" method that's currently available as an example (note the FIXME).

---

krakenex has been at MAJOR version zero since forever - mainly because it hasn't seen much use (well, I haven't seen it used much). E.g., check the issue opening dates - most of them have been opened this year.

Has there been a decision to not include individual python methods for each API method?

Although Kraken's API method names haven't changed since inception (AFAIR), I've decided against it (so far); since, if they did change, that would be tech debt put on me.

However, that was my thoughts up to this year, when many more people seem to have started using it. This pushed me to work toward a v1.0.0 release, that should formalise the package's own API change process.

If this is not the case, are there any plans to implement corresponding python methods anytime soon?

I do not plan to do it myself any time soon - not a priority for me.

Getting v1.0.0 out the door is primary. Getting requests in v2.0.0 follows. Changing API structure can follow after that.

Also, I'd like to retain query_{public,private}() as low-level functionality - since, after all, that's what Kraken's API has as low-level "endpoints".

[veox]

This is also mentioned in issue #11 (as the query() segment, and the only top-level question left unanswered there).

[tasercake]

Please give examples of what you propose.
You probably mean using k.balance() instead of k.query_public('Balance'), and the like?..

That's right, although I think adhering to the names specified on the Kraken API guide would be best.
Something like k.get_trade_balance()

[veox]

A few more thoughts:

This would make sense as an extension of the base API(object) class, e.g. ExtendedAPI(API) or similarly named.

The docstrings can't be copy-paste from Kraken's page (for both licensing and documentation maintenance reasons), but they could include a link to Kraken's docs, and a note on delegation.

[veox]

adhering to the names specified on the Kraken API guide would be best.
Something like k.get_trade_balance()

As to this point, IMO it does not hold. "Get trade balance" is the name of the HTML doc section, not the method (TradeBalance).

(If there was documentation in a different language, the former would have been different, but the latter would be the same.)

[dominiktraxl]

Hi there,

let me first thank you for this package! It's pretty much exactly what I was looking for, nice and neat. The only thing that I thought was missing is the reason for this issue here.

So I took it upon myself and implemented the methods corresponding to the Kraken API methods. See here. The only additional functionality apart from the methods' implementation is a call rate limiter to avoid lockouts.

My implementation deviates substantially from the pull request in #41, but as I think, for a good reason. Just a one-line wrapper around query_public/query_private and copying the docs from Kraken is not really helping anyone, but as it has been said, does put a lot of burden on maintainers. Therefore, I went with a much "higher-level" implementation involving pandas. This serves my needs much better and justifies the extra work regarding maintenance.

If you like the way my implementation is going, I'd gladly work with you to transfer some (or all) of it to krakenex.

[veox]

Hey @dominiktraxl, that's pretty cool, and looks to me like exactly what @tasercake (and @jdddog?) were looking for!

This seems about what I had in mind for krakenex: to be used as a low-level gasket for higher-level interfaces, that transform the portable-yet-unwieldy JSON to whatever format that best suits the use (or user). Bravo!

I don't think there's much need to transfer pykrakenapi's functionality to krakenex, especially since it has its own PyPI package. It would help giving it more exposure, though, so I've linked it in the README.

[dominiktraxl]

Thanks @veox!
I agree with you that it is probably best to keep the low-level krakenex as is, and building other packages on top of it. There's no need to muddle the packages, particularly since not everyone will want to have pandas as a dependency.
I'll give pykrakenapi more exposure once I've tested it more and taken care of some unfinished business. Thank you, however, for mentioning it in the readme!