-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove support for python 2.7 and 3.4 #262
Comments
I'll start: none of my projects making use of this sdk would be negatively affected by switching to 3.5+ only. And several would benefit if this sdk were to have a async api. |
I maintain a Matrix plugin for a chatbot that doesn't yet have Python 3 support, so this would negatively affect me. (Granted, this may be more incentive for the primary developer of that chatbot to switch... :P) |
No problems with that here (to be fair I just started a project). |
Not a problem for me. My project was built and tested under 3.6+ |
Several of my projects (personal and for other organizations) use the python SDK, and are unlikely to switch to python 3 any time soon. That being said, they can keep using the pinned version of the SDK without issue, therefore they aren't greatly affected (until I get the time to update them). |
All of my projects are already 3.5+ and having async/await support would be a massive usability improvement for me. |
No problem here and I think it is the right way to go. |
No problem for me. |
re: @jfrederickson I plan to move the mentioned project to python3 and this would be a good motivator |
just do it |
In our company, internal projects use only 2.7. Therefore, we will have to maintain our fork. |
I hope the impression is not given that the plan is to make everything async. My understanding is that it would be optional parts of the SDK. Also, there are many other advantages to being 3+ only other than the async/await syntax. |
@slipeer I'm curious, does your company already have a migration plan towards Python 3? |
It would be great if this SDK supports micropython, micropython uses async keyword. See also https://github.com/micropython/micropython
|
Here at https://github.com/raiden-network/raiden we are on python 3.6+, so we wouldn't be affected by the switch, although we use a gevent-based wrapper and don't plan to switch to async/await (of course, we wouldn't mind it being optional, and plan to ready and contribute back upstream our optional gevent support) |
@joeky888 just now seeing this. Please feel free to create an issue to document this feature request or a PR. I'm not entirely convinced that the sdk won't already work on micropython, so it might just be a matter of adding something to the CI/test config to make sure tests are run against micropython as well as cpython. |
uuuh, just trying to build a client for SailfishOS (python 3.4) |
What's the sailfishOS devs take on providing python3 with asyncio? |
Just a naive question: is this needed?
It looks like it is in python since 3.4alpha4 and in |
We had a long conversation in
#matrix-python-sdk:matrix.org
a couple weeks ago about the benefit of only supporting versions of python that
support asyncio and came to the conclusion that unless there are major projects
using python 2 or 3.4 that need this sdk, it would be beneficial to the project
to move to being 3.5+ only.
I'd like it if everyone who has a project using this sdk could comment here
briefly saying whether a switch to 3.5+ only would negatively affect their
project or not. It would be great if you could comment regardless of whether it
would or would not affect you.
The text was updated successfully, but these errors were encountered: