Closed sailod closed 3 days ago
Hello @sailod, thanks for your contribution,
However, we don't do these implementations on purpose, we prefer the user to use fetch_open_orders
and fetch_closed_orders
explictly so that he can be aware of the fact that 2 different requests need to be done (and the rateLimit implication of that)
Additionally, all .py files are generated, our development is done using the .ts
version.
@carlosmiei I see but I believe the biggest purpose of ccxt is to unified all the work against exchanges and what if for example there's a code that rely on function which retrieves all orders? wouldn't it be better to allow all options and let the user decide how to use? plus from what I can see the fetch_closed_orders for mexc is still not yet implemented while the fetch_orders is... I understand the TS part, I can write it instead so itll generate the python the right way
@carlosmiei so why to keep the interface with this function ? why for some exchanges it implemented and for some not? if Ill implement fetch_closed_orders() for a missing exchange will that be approved?
@sailod, as I said before, we avoid emulations that require multiple requests. (Having two times the requests makes a huge difference when you're calling these methods hundreds of times per hour.)
if Ill implement fetch_closed_orders() for a missing exchange will that be approved?
yes as long as the implementation is valid (the proper endpoint is used, etc)
this PR adds the fetch_orders() co-routine to support retrieval of orders from the Kraken exchange