Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why not using requests ? #2

Closed
femtotrader opened this issue Jul 7, 2016 · 10 comments
Closed

Why not using requests ? #2

femtotrader opened this issue Jul 7, 2016 · 10 comments

Comments

@femtotrader
Copy link

Hello,

I wonder why you are not using requests

http://docs.python-requests.org/

It's a great library which could help to have same code for both Python 2 and Python 3.

Kind regards

@veox
Copy link
Owner

veox commented Jul 8, 2016

Basically, because I wanted a quick way to access Kraken API and didn't look around. Plus, that's an additional dependency.

Also, I have no interest in Python 2 anymore.

@femtotrader
Copy link
Author

Requests manage parameters encoding, and many other features... and so user code is much lighter.
You really might have a look...
Moreover it's very easy to add a caching mechanism thanks to http://requests-cache.readthedocs.org/
Not a big dependency...

@veox
Copy link
Owner

veox commented Jul 8, 2016

Yup, I did take a short look. :)

Right now, HTTP request handling is a total of 6 lines, including the actual request (in connection.py). I don't see a reason that would justify the effort of putting in an external dependency - to make this code lighter?..

Is there a specific use case where you see requests as superior?

Another concern is that if this code becomes py2+3, then it has to be tested for both py2 and py3. And that's just technical debt.

@veox
Copy link
Owner

veox commented Jul 8, 2016

I took a short look through your repos - do you want to integrate this package in some other tool, that is already using requests? If so, it might be best to just fork and do the changes you desire. It would only be marginally faster than rewriting from scratch though.

@femtotrader
Copy link
Author

For testing both Python 2 and 3, you can create unit tests and use continuous integration (Travis for example). Hide API key using environment variable and your tests will be executed both with Python 2 and 3.

@veox
Copy link
Owner

veox commented Jul 8, 2016

Well, I'm not the one who's going to do any of it any time soon.

OK to close?

@femtotrader
Copy link
Author

that's a pity... unit testing could at least be something to do to ensure your code won't break.

@veox
Copy link
Owner

veox commented Jul 8, 2016

I'll get to it... eventually. It took 2 years to bother generating docs. There's just too much on my plate.

@femtotrader
Copy link
Author

ok ;-)
ping me if you want some tips

nosetests is very easy to use

https://github.com/ig-python/ig-markets-api-python-library/blob/master/tests/test_ig_service.py

You can run tests locally using :

$ nosetests -s -v

Enabling Travis need to be done on their website and you need to add a very basic .travis.yml like
https://github.com/ig-python/ig-markets-api-python-library/blob/master/.travis.yml

A first step could be to test public API calls.

After this, it will be possible to also test private API calls but you will need to secure API key
https://docs.travis-ci.com/user/encryption-keys/

@veox
Copy link
Owner

veox commented Sep 21, 2017

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

veox pushed a commit that referenced this issue Sep 12, 2018
krakenex pull request #2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants