unnecessary abstraction

[solodieyo]

class P2P( P2PRequests ): def __init__(self, **args): super().__init__(**args)
Why do we need an extra layer of abstraction.
This is what causes the typing problem.
Also, all methods do not have parameter or return type typing.

[solodieyo]

Can we raise the minimum version to 3.11 and add TypedDict to requests?

[kolya5544]

class P2P( P2PRequests ): def __init__(self, **args): super().__init__(**args) Why do we need an extra layer of abstraction. This is what causes the typing problem. Also, all methods do not have parameter or return type typing.

It is anticipated that more features might appear on Bybit P2P API at a later point in time. As thus, approach similar to pybit's (mixin-based multiple inheritance pattern) was chosen to allow future separate classes to implement functionality related to different modules -> https://github.com/bybit-exchange/pybit/blob/master/pybit/unified_trading.py#L45

Could you please elaborate what you mean by the "typing problem"?

Additionally, please keep in mind there are currently no plans to standardize or structurize returned values (beyond simple dict) since P2P API is still in active development and experiences frequent changes to the fields returned.

[solodieyo]

1. kwargs in each function, if you switch from the outdated version to 3.11, you can solve the problem using TypedDict and Unpack.

class GedAdsListRequest(TypedDict, total=False):
	status: int
	side: int
	item_id: str
	token_id: str
	page: int
	size: int
	currency_id: str`

 def get_ads_list(
		self,
		**kwargs: Unpack[GedAdsListRequest]
	) -> dict:

Currently, there is no typing for requests from the API, as all methods require **kwargs.
Models for API responses from pydantic or dataclass can greatly simplify the process.

Or maybe something like this?

	def get_current_balance(
		self,
		account_type: str = "UNIFIED"
	) -> dict:
		return self.http_req_handler(
			method=P2PMethods.GET_CURRENT_BALANCE,
			params={"accountType": account_type}
		)

[kolya5544]

Here's a translated version of a message that was shared in an API chat once:

The ideas are generally good, but the primary limitation is the similarity of the code base with pybit. Since Bybit is responsible for the SDK development, we must follow the generally similar style with our official libraries.

In this case, pybit has neither strict data typing nor async support, and as thus there are no plans to deviate from that standard, and therefore PRs implementing such changes most likely will not be merged with the main branch.

However, keep in mind that we do not prohibit users from creating and maintaining their own (unofficial) versions of official packages

We have a very small team working on the SDK, so we would like to limit our exposure to more potential maintenance work in the future.

For this reason, any changes that:
1) completel break previously working code
2) require additional support or maintenance over time, as new features are potentially added to the API
3) require support for additional code, for example, if you decide to combine a sync + async version in one package
... will most likely be rejected and will not be merged

However, I will consider your proposal regarding adding types for values returned.

[kolya5544]

There are currently no plans to drop support for Python 3.9 until its EOL