Make certain unified API methods private/delete them

[ccxt]

Make certain unified API methods private/delete them

[nmiculinic]

And yeah, lack of price isn't clear enough to make it market order; this is a bug waiting to happen. Instead, have parameter type='market' or type='limit' to differentiate between those two.

[kroitor]

The reason for having a huge variety of method signatures was to ease the integration into existing projects, where other libraries may have existed previously with all their different flavours and syntaxes. That load of methods was added to allow code hot-swapping in existing logic. This way it would not require too much in-place rewriting to plug this library into a paper trading strategy or into a fast prototype of a bot.

Yet still, I agree completely, there's a potential pitfall for those who are not careful enough. I will remove excessive methods to minimize that.

What's the difference between this two?

order (symbol, side, amount[, price[, params]])
trade (symbol, side, amount[, price[, params]])

There's no difference, it's an alias, legacy, for same reasons, mentioned above. There are 3 methods with same signature but different names: createOrder == order == trade. I will clean it up, of course.

Also is there any reason for keeping camelCase in python, instead of using only underscores? PEP8 standard defines how python code should look like, and I assume your users are using it; it's trivial converting camelCase to underscore in the head; much less trivial if there's a typo somewhere and you accidentally call the wrong function.

The reason for keeping both camelCaseNames and names_with_underscores is cross-compatibility, the ability to copy-paste between languages (or close to that, without too many significant changes). This helps interoperability among the community of the users of the library, who prefer different languages, but would still be able to understand each other.

The JS → Py/PHP transpiler currently does not convert internal public/private API calls to underscore-style inside method bodies. But I will finish the name conversion stage and all Python names will conform to PEP standards really soon, I hope.

And yeah, lack of price isn't clear enough to make it market order; this is a bug waiting to happen.

I'll make the price/ordertype more explicit and restrict the set of methods, thanks for pointing that out.

[kroitor]

Ok, I cleaned up the set of methods leaving only the following:

# Python
.create_market_buy_order (symbol, amount[, params])
.create_market_sell_order (symbol, amount[, params])
.create_limit_buy_order (symbol, amount, price[, params])
.create_limit_sell_order (symbol, amount, price[, params])

... and their camelCase aliases. Everything else is gone from now on, no typo-mistakes anymore )

I also left in place just one single generic create_order () method, but I will explicitly mention the risks of using it in the docs.