Return to Question

BitEx is a python module I've been working on for a little over 9 months now, as a side project. It was published 6 months ago on GitHub, and as I edge closer to my 1.0 release, I wanted to take the opportunity to present my code on here, in order to straighten it out.

##What it solves and offers## It's designed to eliminate the need to get into the gory details of REST APIs of crypto exchanges, and offer a homogeneous and intuitive interface for all supported APIs. It takes care of authentication procedures, and offers a standardized set of methods (with identical method signature) for all commonly used methods at an exchange (polling order book & tickers, placing and cancelling orders, amongst others), as well as all other specific methods (or as many as I had the time to implement thus far).

The other is bitex.interfaces, which offers the above mentioned homogenous, standardized methods for all implemented exchanges. In addition to offering identical method signatures, it also aims to standardize method's return values. As these can differ significantly from exchange to exchange, these methods take care of data formatting, via the help of formatters found in bitex.formatters and the return_json decorator. It relies on bitex.api.

Over the past two months, however, I've become rather fond and proud of the current structure and deem it quite presentable - enough so, to have it publicly audited. I have read the meta question on how to get the best value out of my review, and quite initially settled on having three 'rounds' of reviews for my code:

1. Round: Code-Style [Completed] PEP8, readability, pythonic-ness

2. Round: Refactoring Options and the evaluation of present layout
   Especially API Class's sign() method, return_json() decorator and usage of formatter funcs

3. Round: Flaws, Improvements in code & logic, Bugs etc
   General logic flaws / improvements, bugs, etc

Please let me know if this agrees with the site's best practices.

##Review Round 2: Re-Factoring & Layout## I have especially my worries about the bitex.api sub-module. The sign() method is difficult to generalize as it is since the inputs vary massively, forcing me to pass everything to them. I was not able to come up with a more sensible solution.

And lastly, the use and design of bitex.formatters to format returned data from bitex.interfaces classes via the @return_json decorator (which may be slightly ill named, by now, since it no longer just returns the requests.response json value). Is mine an acceptable approach? It seemed like the most straight-forward solution (as opposed to cluttering each Interface class with the formatting directly).

#Code# ##bitex.api##

BitEx is a Python module I've been working on for a little over 9 months now, as a side project. It was published 6 months ago on GitHub, and as I edge closer to my 1.0 release, I wanted to take the opportunity to present my code on here, in order to straighten it out.

##What it solves and offers##

It's designed to eliminate the need to get into the gory details of REST APIs of crypto exchanges, and offer a homogeneous and intuitive interface for all supported APIs. It takes care of authentication procedures, and offers a standardized set of methods (with identical method signature) for all commonly used methods at an exchange (polling order book and tickers, placing and cancelling orders, amongst others), as well as all other specific methods (or as many as I had the time to implement thus far).

The other is bitex.interfaces, which offers the above mentioned homogeneous, standardized methods for all implemented exchanges. In addition to offering identical method signatures, it also aims to standardize method's return values. As these can differ significantly from exchange to exchange, these methods take care of data formatting, via the help of formatters found in bitex.formatters and the return_json decorator. It relies on bitex.api.

Over the past two months, however, I've become rather fond and proud of the current structure and deem it quite presentable - enough so, to have it publicly audited.

I have read the meta question on how to get the best value out of my review, and quite initially settled on having three 'rounds' of reviews for my code:

1. Round: code style (completed), PEP8, readability, pythonic-ness

2. Round: Refactoring options and the evaluation of present layout, especially API class' sign() method, return_json() decorator and usage of formatter funcs.

3. Round: flaws, improvements in code and logic, bugs, etc.

##Review Round 2: Refactoring and Layout##

I have especially my worries about the bitex.api sub-module. The sign() method is difficult to generalize as it is since the inputs vary massively, forcing me to pass everything to them. I was not able to come up with a more sensible solution.

And lastly, the use and design of bitex.formatters to format returned data from bitex.interfaces classes via the @return_json decorator (which may be slightly ill named, by now, since it no longer just returns the requests.response JSON value). Is mine an acceptable approach? It seemed like the most straightforward solution (as opposed to cluttering each Interface class with the formatting directly).

##bitex.api##

This is a follow up to my previous review request.

This is a follow up to my previous review request.

Over the past two months, however, I've become rather fond and proud of the current structure and deem it quite presentable - enough so, to have it publicly audited. I have read the meta question on how to get the best value out of my review, and quite initially settled on having three 'rounds' of reviews for my code:

Over the past two months, however, I've become rather fond and proud of the current structure and deem it quite presentable - enough so, to have it publicly audited. I have read the meta question on how to get the best value out of my review, and quite initially settled on having three 'rounds' of reviews for my code: