RFC: SkPy and asyncio

[Terrance]

Currently, SkPy is a synchronous library with support for Python 2.6 and above. The underlying HTTP calls are made using Requests. Because the long-polling requests used to wait for messages are blocking, it makes it difficult to integrate with other projects.

Python 3.4+ (or 3.3+ via backport) provides the asyncio library, which allows multiple classes or programs to run in parallel by yielding during background operations (network requests and I/O). Many other chat frameworks such as hangups or discord.py, and HTTP libraries like aiohttp, make use of asyncio.

Implications of switching to asyncio:

• Dropping support for Python 2.x and <3.3. All currently supported versions of Ubuntu now ship with at least Python 3.4, so availability should not be an issue. Using async/await syntax would require 3.5, which for Ubuntu has still been around since the 16.04 LTS.
• Incompatible API changes. Any existing code using SkPy would need updating to work with coroutines (i.e. await or yield from when calling most methods). Initialising a Skype session would also mean interacting with event loops. It would also be nice to use this opportunity to improve PEP 8 compliance by switching to snake_case method names rather than camelCase.

This issue invites existing users to chime in on their usage of SkPy so far, and whether the switch would cause any problems. Note that old versions are available on PyPI and GitHub, but won't receive any updates should a breaking change appear upstream.

[hugovk]

Python 2.6 and 3.3 are both EOL and no longer receive security updates (or any other kind) from the core Python team. They're also little used.

Here's the pip installs for SkPy from PyPI for last month:

python_version	percent	download_count
2.7	42.6%	66
3.6	40.0%	62
3.5	16.1%	25
3.4	1.3%	2

Source: pypinfo --start-date -58 --end-date -28 --percent --pip --markdown SkPy pyversion

I'd recommend dropping at least 2.6 and 3.0-3.3.

As for 2.7, some projects have already dropped or planned to drop it before it becomes EOL in 2020. See http://www.python3statement.org.

And SkPy had more Python 3 installs in December than Python 2.

If using asyncio means the maintenance burden drops and new features can be implemented more easily, I think it's probably a good idea to go for it.

You can use python_requires to make sure people using older Python version get the correct version installed. See https://stackoverflow.com/a/44660547/724176.

[Terrance]

For me, I have two asyncio-first project that I'd like to plug SkPy into, but asyncio really doesn't cater for non-async-aware code -- it usually means faff with executors and threads. That said, having used asyncio quite extensively now, I am preferring it for all my web-based projects.

The download stats are interesting, I probably should have checked them first. 🙂 I agree that there's no need to support 2.6 or early 3.x (2.6 support only exists because it was a single line change to make it so). 40% on Python 2.7 is a significant chunk though.

As a lurker in a few other Python library discussions, I note that asyncio tends to cause more confusion for those with limited Python experience, and I realise that quite a few question-based issues raised here are from users just starting out with Python. As such, the barrier of entry will be higher, though I'd argue this library probably isn't a great place to start with Python anyway...

[rooterkyberian]

https://pythonclock.org/

The python_requires should be enough assurance to guarantee whoever still uses Python 2.7 that his/hers application will not be broken by the new SkPy releases.
I don't think its a good idea to be held back by users that are not willing to update. If they do not want to update Python interpreter, then I guess they should be fine with not updating libraries as well.

Much more convincing argument IMO is that making library API async makes it harder for beginners, but I would argue SkPy is not beginner friendly anyway, and as async becomes more common it will be easier as well. With Python 3.7, running async function is as easy as asyncio.run(async_func()), so while it still requires additional function call this is already so much better than it was in previous version.

[Terrance]

making library API async makes it harder for beginners, but I would argue SkPy is not beginner friendly

Agreed -- I lurk in the GitHub issues section of a few asynchronous libraries I use, and there's always a lot of confusion over how to interact with asyncio correctly. Having worked with it in a few projects now, it's a powerful framework well-suited to HTTP-based "clients" for services like Skype, but it does significantly raise the barrier to entry for working with the library.

Looking at the issues here, a lot of them are raised by people with limited Python knowledge (despite my hinting that they need to start with something simpler to learn Python), and going async will undoubtedly bring in more of such issues.

Ultimately I want to go ahead and do it, though my use of Skype in general has dwindled, leaving SkPy in the backburner, and rewriting for asyncio is somewhat of a significant undertaking.

[codeofdusk]

Any updates on this issue?

I'd love to make Amanda async for a variety of reasons (including easing writing new drivers), but Skype/skpy is currently the primary protocol...

[Terrance]

I think my stance above still stands, I haven't used Skype in personal capacity for years now (not particularly fond of the direction it's taken, plus ~nobody I need to talk to still uses it either). 😩

Probably the only interest I have in modernising it would be to pull it into my general chat framework IMMP, but it remains a significant undertaking to port the basics to async and rewrite the API to match the framework.