Example from README do not work on Debian Squeeze

[petterreinholdtsen]

I tried to use this module on Debian Squeeze with the example code found in the readme, but get this exception:

pere@minerva:~/src/bitcoin/mexbtcapi$ cat x.py import mexbtcapi from mexbtcapi.concepts.currencies import USD from mexbtcapi.concepts.currency import Amount

ten_dollars= Amount(10, USD) for api in mexbtcapi.apis: exchange_rate= api.market(USD).getTicker().sell print "At %s I can get %s for my %s (that's %s)"%(api.name, exchange_rate.convert( ten_dollars ), ten_dollars, exchange_rate) pere@minerva:~/src/bitcoin/mexbtcapi$ pere@minerva:~/src/bitcoin/mexbtcapi$ python x.py Traceback (most recent call last): File "x.py", line 7, in exchange_rate= api.market(USD).getTicker().sell File "/home/pere/src/bitcoin/mexbtcapi/mexbtcapi/api/mtgox/http_v1/high_level.py", line 20, in init self.multiplier= low_level.multiplier[ currency.name ] #to convert low level data File "/home/pere/src/bitcoin/mexbtcapi/mexbtcapi/api/mtgox/httpv1/mtgox.py", line 51, in getitem info = currency(currency) File "/home/pere/src/bitcoin/mexbtcapi/mexbtcapi/api/mtgox/http_v1/mtgox.py", line 119, in currency return _generic('currency', data=data) File "/home/pere/src/bitcoin/mexbtcapi/mexbtcapi/api/mtgox/http_v1/mtgox.py", line 96, in _generic return _json_request(url, data) File "/home/pere/src/bitcoin/mexbtcapi/mexbtcapi/api/mtgox/http_v1/mtgox.py", line 109, in _json_request jdata = json.load(f, object_pairs_hook=_pairs_hook) File "/usr/lib/python2.6/json/init.py", line 267, in load parse_constant=parse_constant, _kw) File "/usr/lib/python2.6/json/init.py", line 318, in loads return cls(encoding=encoding, _kw).decode(s) TypeError: init() got an unexpected keyword argument 'object_pairs_hook' pere@minerva:~/src/bitcoin/mexbtcapi$

Is it a bug in the library or something else wrong?

[goncalopp]

I can reproduce this using debian squeeze.

I isolated it to a limitation in the json parser library. As the trace indicates, it seems the mtgox httpv1 library is using the object_pairs_hook functionality.

As the documentation (http://docs.python.org/2/library/json) states, this functionality was added in python 2.7. Debian squeeze is still using 2.6.

I've added a note to the README, indicating 2.7 is required for the current codebase.

[petterreinholdtsen]

I can reproduce this using debian squeeze.

Great.

I isolated it to a limitation in the json parser library. As the trace indicates, it seems the mtgox httpv1 library is using the object_pairs_hook functionality.

Right. Is it important to use this object_pairs_hook functionallity? I read a bit about it, and its main purpose seem to be to keep a stable ordering in a dict().

Using this patch, I got the library working with the python version in Debian Squeeze. I assume I lost some predicable ordering of the json data structure, but it did not affect the test script at least.

diff --git a/mexbtcapi/api/mtgox/http_v1/mtgox.py b/mexbtcapi/api/mtgox/http_v1/mtgox.py index adda46c..1f16409 100644 --- a/mexbtcapi/api/mtgox/http_v1/mtgox.py +++ b/mexbtcapi/api/mtgox/http_v1/mtgox.py @@ -56,7 +56,7 @@ class _Multiplier(dict):

multiplier = _Multiplier()

-def _pairs_hook(pairs): +def _value_hook(values): d = dict() ideal = None keep = None @@ -77,7 +77,8 @@ def _pairs_hook(pairs): drop = ('currency', 'amount', 'price', 'value', 'item', 'price_currency', 'amount_int', 'price_int', 'value_int')

• for k, v in pairs:
• for k in values:
• v = values[k] if k in drop: continue elif k in keep: @@ -106,7 +107,7 @@ def _json_request(url, data=None): else: req = urllib2.Request(url) f = urllib2.urlopen(req)
• jdata = json.load(f, object_pairs_hook=_pairs_hook)

• jdata = json.load(f, object_hook=_value_hook)

  if jdata['result'] == 'success': return jdata['return']

With this change in place, I get this output:

pere@minerva:~/src/bitcoin/mexbtcapi$ python x.py At MtGox I can get 1.34 BTC for my 10.00 USD (that's 13.39 USD/BTC) pere@minerva:~/src/bitcoin/mexbtcapi$

Happy hacking Petter Reinholdtsen

[goncalopp]

mtgox.py was "inherited" as the base for this project. I didn't write it, and I've been meaning to go through it for a long time, since it has a lot of (now) unnecessary functionality, but since it mostly works, it's not on my top priorities.

Right. Is it important to use this object_pairs_hook functionallity? I read a bit about it, and its main purpose seem to be to keep a stable ordering in a dict().

I've gone over it and, indeed, you're absolutely correct. Moreover, since python's (bare) dict (which is used to return the values) is unordered, using object_pairs_hook seems useless here.

Using this patch, I got the library working with the python version in Debian Squeeze.

Thank you! I've applied it with a slight change, and it seems to be working. It's in the current master

Let me be the first to say: if you're intending in using this library in production, be aware that is pretty much a work-in-(slow-)progress. Most of the generalized datastructures are there, but much functionality is still missing. I feel like it's a solid base, though, and if you're interested in furthering the implementation, I'll be more than happy to review and commit patches

[petterreinholdtsen]

mtgox.py was "inherited" as the base for this project. I didn't write it, and I've been meaning to go through it for a long time, since it has a lot of (now) unnecessary functionality, but since it mostly works, it's not on my top priorities.

Right. Then I guess most of the stuff there isn't needed.

Thank you! I've applied it with a slight change, and it seems to be working. It's in the current master

Great.

Let me be the first to say: if you're intending in using this library in production, be aware that is pretty much a work-in-(slow-)progress. Most of the generalized datastructures are there, but much functionality is still missing. I feel like it's a solid base, though, and if you're interested in furthering the implementation, I'll be more than happy to review and commit patches

At the moment I am just testing different APIs, to see if any are useful to create a trading robot.

The library seemed like a good start, but the "multi marked" feature is a bit short. Are you planning on adding more markeds? I had a look at the API available from "https://www.bitstamp.net/api/", but do not quite understand how to add support for it in the library. Perhaps you can give it a try?

Happy hacking Petter Reinholdtsen

[goncalopp]

On 27-12-2012 19:30, petterreinholdtsen wrote:

The library seemed like a good start, but the "multi marked" feature is a bit short. Are you planning on adding more markeds? I had a look at the API available from "https://www.bitstamp.net/api/", but do not quite understand how to add support for it in the library. Perhaps you can give it a try?

As stated in the README, the objective of this project is, first and foremost, to have a well-developed set of interfaces for the lower-level libraries (API parsers) to use. Hopefully, anyone developing a new API parser could take the time to implement those interfaces in their code.

I may get around implementing a bitstamp parser - but, since you mention the problem, maybe documentation on HOW to integrate such parser in this library in more needed, at this point.

[petterreinholdtsen]

As stated in the README, the objective of this project is, first and foremost, to have a well-developed set of interfaces for the lower-level libraries (API parsers) to use. Hopefully, anyone developing a new API parser could take the time to implement those interfaces in their code.

I may get around implementing a bitstamp parser - but, since you mention the problem, maybe documentation on HOW to integrate such parser in this library in more needed, at this point.

Perhaps. It is just that in my experience, API design of abstraction layers intended to hide the complexities of other APIs become better by implementing support for two or three of them. I suspect the API need a bit more work before it is "generic". For example, I tried to implement the getTicker() call for Bitstamp, and discovered that the underlying API lack the average value. Should it be a default part of the API? I do not know, but suspect those looking at these issues will end up changing the API slightly. :)

Happy hacking Petter Reinholdtsen

[goncalopp]

Indeed, having more markets supported will lead to a looser coupling with any one of them - only by doing that can one identify common "base functionality". I see you're implementing bitstamp, so I'll try to work closely with you on that