Parsing of numbers from json loses precision

[s4w3d0ff]

Parsing of numbers from json loses precision

[s4w3d0ff]

Thank you, you are 100% correct, I had noticed this behavior a few months back and opened a support ticket with polo to try and figure out where the rounding was coming from (thinking it might have to do with something on their end), I had never really figured it out and the bug 'disappeared.' Seems this was the initial problem to begin with.

TBH I had no idea the json module could convert values while decoding.

I'll make the commit directly to master PR and publish a release sometime today.

[s4w3d0ff]

Poloniex data sets are not consistent across api commands, some return numbers others return strings when you would expect numbers.

{u'bids': [[u'0.00062074', Decimal('2.41647066')],,,],}

This PR shouldn't hurt anything, but if poloniex decides to switch its unicode numbers to floats/decimals, things might get a little buggy/inconsistent if users are doing high precision math from these raw data sets.

[goncalopp]

thinking it might have to do with something on their end

Actually, you're right here. As you've noticed, they're encoding number-likes as both json strings and number in the same message - exchange rate is a string, amount is a float.

I'm not sure whether that means that the original amount is stored as a float on their backend, or that they botched the REST code - in either case, it seems some shoddy coding on their end.

With that being said, we (library developers) should strive to give as much precision as we possibly can with what the service gives us.

if poloniex decides to switch its unicode numbers to floats/decimals, things might get a little buggy/inconsistent

That's a good point. Maybe we can parse_float=str, and let the user deal with it?

[s4w3d0ff]

I agree, parse them as strings and let the user choose how they want to convert is probably best. Not sure if just strwill do it for both python 2 and 3 (maybe unicode or a futures class) but I will push the commit to #32 and test asap

[goncalopp]

str should work as intended in python3. In fact, unicode doesn't exist anymore

[s4w3d0ff]

Here is my test using str

Python 2.7.12
>>> import poloniex
>>> polo = poloniex.Poloniex()
>>> polo.returnOrderBook('BTC_CGA')
{u'bids': [[u'0.00062355', '2.40558095'],,,

Python 3.5.2
>>> import poloniex
>>> polo = poloniex.Poloniex()
>>> polo.returnOrderBook('BTC_CGA')
{'asks': [['0.00066485', '116.26734022']

[s4w3d0ff]

OK... so #33 should fix the string inconsistency between python 2 and 3 (using unicode and str):

Python 3.5.2
>>> from poloniex import Poloniex
>>> Poloniex().returnOrderBook('BTC_CGA')
{'bids': [['0.00062461', '4.00256164'],

Python 2.7.12
>>> from poloniex import Poloniex
>>> Poloniex().returnOrderBook('BTC_CGA')
{u'bids': [[u'0.00062461', u'4.00256164'],

I think we are good for a release.
Just a small change then I think it will be ready for release, the nonce increment needs to be moved...

[goncalopp]

I noticed you released 0.2.1
Thank you for your efforts, it's great to be able to have proper decimal precision!
In case it interests you, I'm pulling this into the experimental branch of mexbtcapi

[s4w3d0ff]

No problem, thanks for the help!

[s4w3d0ff]

I am starting not to like what we did 🙄 I'm probably going to make this all optional and allow the user to define what datatype they want to use for numbers. Probably should have been done in the first place... :P

[s4w3d0ff]

see #68