Simplify connection handling (by using `requests`) about python3-krakenex HOT 16 CLOSED

Ok I have pushed the changes I mentionned in my last comment. As expected, they don't change much to the actual call to your query_* functions (in fact it even makes it a bit clearer to get rid of the func(*args) call).

So just to explain my code a little bit, my implementations of the different kraken api methods look like that:

res = query_api('public', 'Ticker', api_params, args)

where query_api(api_type, api_method, api_params, ck_args) is the wrapper function I wrote to call krakenex. In query_api() I select the correct method from your API (here instanciated in gv.KRAKEN_API) based on the first positional argument of my wrapper function (api_type is either 'private' or 'public'):

# just a mapping from api_type to the function to be called
api_func = {
    'public': gv.KRAKEN_API.query_public,
    'private': gv.KRAKEN_API.query_private
}
# select the appropriate method depending on the api_type string
func = api_func.get(api_type)

This is a bit overkill because an if/else would have done just fine, but it allows potential easy extensibility.

Then I just call the api method like this:

try:
    # call to the krakenex API
    res = func(api_method, api_params)
except (socket.timeout, socket.error, http.client.BadStatusLine) as e:
    ...

So, TL;DR: I added my own connection handling when I call your function. I also check for other types of error messages from kraken's response.

However as you can see in my code, I only silence the connection errors and the invalid nonce errors when in "cron mode". In interactive mode, I chose to let them be errors outputted to the user.

That being said, I still need to tackle your questions individually, but for now I've got to sleep, so I'll answer them tomorrow 😉

from python3-krakenex.

Thanks @zertrin! I'll try and take a look soon. BTW, there is no rush. :)

Luckily, krakenex's now on PyPI, so you could specify

install_requires = [
    'krakenex>=0.1,<1.0',
    ...]

in setup.py in the meanwile.

from python3-krakenex.

I've decided to check what implementing this would entail. See a pre-alpha quality draft in the requests branch if interested.

It's based off master, a few commits after tag v1.0.0a0, and itself bumps the version to v2.0.0a0 (in krakenex/version.py). The latter is not present as a git tag.

Seems to more or less work with examples/depth.py and examples/get-available-balance.py. Haven't tried placing orders (yet).

git history is dirty (will squash/rebase as needed). Documentation hasn't been updated. Functions that previously had req now use data instead. I'm also thinking of renaming Connection to Session.

Haven't tested proxies, timeouts, and all the other requests features at all. Should be possible to do by accessing the Connection.session attribute.

With that draft impl-n, it's technically possible to remain backwards-compatible with the current krakenex API (would just need to change data back to req everywhere).

However, the introduction of a dependency warrants a MAJOR version bump anyway IMO.

from python3-krakenex.

I think the current http.client is not thread safe it seems, requests uses urllib3 which is. Am i correct in thinking this or is there a way to get around this in your api?

from python3-krakenex.

So far this branch is 100 times better than master.

from python3-krakenex.

On "connection handling" - IMO specifying an API URI other than api.kraken.com should remain possible, since this may be used for testing against a "mock" market.

from python3-krakenex.

Ping @femtotrader, @wwender, @zertrin.

I'm trying to figure out what krakenex should do this time, instead of "I need this bot to talk to this exchange, fast".

A common request so far has been to use requests. You folk have seemingly tried to use krakenex at least once, and would be possibly affected by made decisions.

from python3-krakenex.

Another option, instead of introducing requests in v1.0, is making another package, e.g. krakenfx (for a nice name collision with Kraken's twitter).

from python3-krakenex.

@veox thanks for the mention. I need to wrap my head about the implications of such a change, and given my timezone (UTC+8), I won't be able to do it before at least tomorrow.

In the meantime, you can have a look at the wrapper function I wrote to interface with your API: https://github.com/zertrin/clikraken/blob/master/clikraken/api/api_utils.py#L43

Coincidentally I was looking tonight at making minor changes in this function, to refactor a bit some duplicated code from other parts of my code (related to the user choice (args.raw) of outputting the raw json instead of the formatted output that is the main goal of clikraken). These planned changes on my side are however independent from this issue.

from python3-krakenex.

@Dudey007 Not sure I understand ("thread-safe" is a loaded term), but yes, assume the current approach in krakenex not to be "thread-safe" at all.

Furthermore, the load balancing done on Kraken's side would mean that if you have several connections open at the same time, you can't guarantee that you're talking to the same machine on the other end.

The above seems somewhat OT, though. :/

from python3-krakenex.

@skyl, @jdddog - could you clarify on "better"?

Do networking errors like in issue #52 not happen? Something else?..

from python3-krakenex.

I repeatedly had problems cancelling orders with latest version from pip, it seems to work fine with this version though. I can try again and let you know what the actual error was.

from python3-krakenex.

Kraken API is so undependable, it's hard to say. I haven't been using it much. I still get plenty of errors from Kraken, mostly 5XX errors that I don't think this library could help with. One class of errors was remedied by switching to this branch but I don't remember the specifics.

from python3-krakenex.

Thank you both for the prompt reply!

I asked on the off chance that you might've remembered the details. There's no need to get back to a less stable implementation just to satisfy my curiosity. :)

EDIT: I'm fairly certain it's requests' graceful handling of timeouts, or the like.

from python3-krakenex.

Due to #53, I've decided to push forward with this ASAP. There's a post-v1.0.0 branch, requests-updated, that drops the Connection class entirely. (This branch will be merged into master soonish.)

There's now a session property on API objects, which is a requests.Session. Fiddling with k.session directly should allow all "custom" setups.

I've tried it with the few present examples, both private and public queries; but haven't tried order placing yet.

Sadly, I have to run now, but should get back to this by the end of the week.

from python3-krakenex.

requests-updated has been merged to master. Also released v2.0.0a1 (alpha).

from python3-krakenex.