Skip to content
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

Open
non-Jedi opened this issue Jul 29, 2018 · 20 comments
Open

Remove support for python 2.7 and 3.4 #262

non-Jedi opened this issue Jul 29, 2018 · 20 comments

Comments

@non-Jedi
Copy link
Collaborator

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.

@non-Jedi
Copy link
Collaborator Author

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.

@jfrederickson
Copy link
Contributor

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)

@johnpwarren
Copy link

No problems with that here (to be fair I just started a project).

@eternal-flame-AD
Copy link
Contributor

Not a problem for me. My project was built and tested under 3.6+

@turt2live
Copy link
Member

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).

@Cadair
Copy link
Contributor

Cadair commented Jul 30, 2018

All of my projects are already 3.5+ and having async/await support would be a massive usability improvement for me.

@Zil0
Copy link
Contributor

Zil0 commented Jul 30, 2018

No problem here and I think it is the right way to go.

@mvgorcum
Copy link

No problem for me.

@jahschwa
Copy link

re: @jfrederickson I plan to move the mentioned project to python3 and this would be a good motivator
jahschwa/sibyl#35

@4nd3r
Copy link

4nd3r commented Jul 31, 2018

just do it

@slipeer
Copy link

slipeer commented Aug 12, 2018

In our company, internal projects use only 2.7. Therefore, we will have to maintain our fork.
I do not quite understand why you can not leave this SDK and make 3.5+ fork, for example matrix-python-async-sdk.
For many simple tasks, asynchrony is an unnecessary complication.

@Cadair
Copy link
Contributor

Cadair commented Aug 12, 2018

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.

@Croydon
Copy link
Contributor

Croydon commented Aug 12, 2018

@slipeer I'm curious, does your company already have a migration plan towards Python 3?

http://pythonclock.org

@joeky888
Copy link

It would be great if this SDK supports micropython,

micropython uses async keyword.

See also https://github.com/micropython/micropython

MicroPython implements the entire Python 3.4 syntax (including exceptions, with, yield from, etc., and additionally async/await keywords from Python 3.5)

@andrevmatos
Copy link

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)

@non-Jedi
Copy link
Collaborator Author

@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.

@joeky888
Copy link

@non-Jedi

Sure, here it is.

#287

@cy8aer
Copy link

cy8aer commented Feb 11, 2019

uuuh, just trying to build a client for SailfishOS (python 3.4)

@ptman
Copy link

ptman commented Feb 12, 2019

What's the sailfishOS devs take on providing python3 with asyncio?

@cy8aer
Copy link

cy8aer commented Feb 12, 2019

Just a naive question: is this needed?

,---
| Sailfish OS 3.0.1.11 (Sipoonkorpi)
'---
[nemo@wilf ~]$ python3
Python 3.4.3 (default, Aug 10 2018, 07:11:41) 
[GCC 4.8.3 `20140401` (Mer 4.8.3-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> 

It looks like it is in python since 3.4alpha4 and in __init__.py 3.3 is mentioned too (there selectors module is missing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests