What work would be required to make the main repo async?

[kaneryu]

I already have a working async version that's reasonably up to date, so it's possible. I was wonder what was your requirements to make this main repo async? A library like this shouldn't be sync, in my opinion. I believe it's of great interest to users to make it async. I'm willing to work on this main branch to make it asynchronous. I'm just wondering if it's a firm no, if it's a firm no then why? And if it's not a firm no, what's stopping us, and what work would have to be done to start making this library async.

[sigma67]

Preface: I personally have little experience with async in Python.

My main concerns would be twofold:

• significant refactor required and the library may become harder to maintain as a result
• it might not be possible to implement it without breaking changes

I also personally don't have a use for it, and consider other topics more important (like #307), so that's why I haven't started on it. I do realize that this is a frequently requested feature, although it can be worked around via wrapper executors.

Also consider #328 (comment) , albeit admittedly sync/async is likely not going to stop anyone from abusing the library (as evidenced by the comments there).

I'm willing to accept a PR on this if you can convince me that the two main concerns above are not warranted.

[kaneryu]

You can look at https://github.com/kaneryu/ytmusicapi (async stuff is on the async-new branch)
It will require a medium refactor but once it's done development will be very similar (look at the individual functions, for example in browse.py, the only difference is await self._send_request ....

As for usefulness, we often have to do multiple calls, like getting song information multiple times to retrieve detailed information about songs from a playlist, or maybe liking multiple songs from a playlist, etc etc that could benefit from async.

For the abuse issue, admittedly accidental abuse would be easier. I'm actually not sure on the default limit on concurrent awaits, but without using anything to limit it there could be somebody sending out a large amount of requests at once. However I don't think that's a huge issue, because they'd just run into their individual rate limits and not everyone needs async

Which brings me to the final point, a lot of people really do just want to run a function or two, like converting their playlist into json, or something like that, this should be just fine for them. As long as the wrap it in an async def main they don't even have to use await on each function.

[sigma67]

You did not address my second point - the possibility to implement this without breaking changes to the user. This is the most important point actually.

Can you make a proposal that does not involve any changes for users of the existing API? Unless they explicitly want to opt-in use the new async functionality.

[kaneryu]

Hmm.. Why not have a separate async version? Both versions would be stored side by side in this repo (two top level folders, like sync/ and async/.
Every commit would need to add functionality into both sides, but that's not a large issue because the code is almost identical on either side, basically, the async version just adds awaits everywhere (though it does rework the http session handler and login iirc).
This would add some development overhead.

The best solution would be to replace sync functionality, but that would be too hasty considering the large preexisting userbase.

[FisHlaBsoMAN]

Without a doubt, after the library switches to asynchronous operation, everyone who uses old version will have to rewrite their code. At a minimum, they'll have to convert their functions to async and add "await" before using lib functions.
But in its current form, you have to resort to various hacks and hacks like "async wrap" to prevent the program blocking the interface during requests. Synchronous code (not async) makes the library much harder to control and less convenient to use. It's not even about parallel requests, but about blocking event loop. This is especially relevant in cases of poor internet connectivity or is has API errors, as it can negatively impact the user experience. It's almost 2026, but asynchronicity in python was added 10 years ago.

[kaneryu]

Yes, I agree completely, thank you.

[sigma67]

The library will not switch from sync to async.

For this to make it into main the async API will have to be separate, and opt-in.

For example: from ytmusicapi import YTMusicAsync

There should be no changes for existing users. I'm convinced that this is possible with some refactoring. If it is not please elaborate.

[kaneryu]

Yeah, I think it's possible too.