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

Consider Upgrading Python 3.5+ Asyncio #66

Open
slick666 opened this issue May 30, 2016 · 4 comments
Open

Consider Upgrading Python 3.5+ Asyncio #66

slick666 opened this issue May 30, 2016 · 4 comments

Comments

@slick666
Copy link

Python 3.5 incorporated updated the the asyncio.

PEP 492 - Coroutines with async and await syntax

Lets consider upgrading to the latest version of python asyncio and syntax going forward and possible back-porting these updates into the current code.

@pypingou
Copy link
Collaborator

While a good idea, especially when looking into the future, this would make it harder to run ircb on more stable/server distro such as RHEL or CentOS

@slick666
Copy link
Author

@pypingou, While I agree I believe we're already in a 3.4+ situation with the codebase as it is. With RHEL/Centos only supporting 3.3+ I don't see us in any worse state. In other words if 3.4 why not 3.5?

@rtnpro
Copy link
Member

rtnpro commented May 31, 2016

@slick666 I agree with @pypingou on this. I think we need to consider compatibility with stable/server distro like RHEL and CentOS. The reason we had to move to Python3.5 was due to a dependency on https://github.com/gnarlychicken/aiohttp_auth. We might need to either use a forked version of the above library with supports Python 3.4/3.3.

@slick666
Copy link
Author

I'm of two minds about this. I understand the conundrum and agree with the direction. RHEL/Centos has always had poor python support and while it's ubiquity is undeniable I'm skeptical that we can ever fit onto a RHEL7 box with a python asyncio based application. Python 3.4/3.5 are supported on Ubuntu's latest LTS which offers some hope I know its not something that everyone will embrace. (My team at work wouldn't.) I'm all for making this an platform agnostic and flexible as possible but I don't want to give us impossible goals.

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

No branches or pull requests

3 participants