-
Notifications
You must be signed in to change notification settings - Fork 31
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
In moving toward python3, do we want to maintain backwards compatibility? #265
Comments
There is a backport of asyncio called trollius that we want to use. It has alternate syntax for 'yield from', 'await' and other python 3isms, and you can also use it in python 3 until you make the complete transition. |
@ejeffrey As illustrated in my previous comment, and as you said, trollius does not provide the really nice asyncio syntax. So, if we use trollius then I guess you're saying we should simultaneously support python 2 and 3? |
Basically I think we should use trollius as a stepping stone. I don't
I should point out that async def and await were only added last On Sat, Jun 25, 2016 at 4:08 PM, Daniel Sank notifications@github.com
|
Yeah that makes sense. It's unfortunate that the Python 3 asynchronous APIs On Jun 25, 2016 6:58 PM, "ejeffrey" notifications@github.com wrote:
|
@ejeffrey plan makes a lot of sense. If internally the plan is to use Python 3 going forward then the concern is for external users. FWIW, I'm happy to move on to Python 3. The extra effort to maintain backwards compatibility with Python 2 sounds like a significant resource sink. Maybe a 2b) would be some rough guide on how to switch from pylabrad on Python 2 to Python 3. If current code style at this point can better accommodate a 2 to 3 switch that would be great to know. |
Using trollius to revamp the networking backend is a good idea; it allows us to not depend on Twisted and makes some parts of the code easier to understand and maintain. Note that |
The biggest problem with porting to python 3 other than twisted To this end, we have already added the 'y' type for bYtes. Currently, All of this can be done easily in both python2 and 3, so it won't really Most of the other changes are pretty simple and mechanical, like using On Mon, Jun 27, 2016 at 1:17 PM, jayich notifications@github.com wrote:
|
After we enable Python 3.x and before we drop Python 2.7 support, we should probably wait somewhere between 6 months and 2 years for external users to make the switch. During this time, we should probably raise a DeprecationWarning to indicate that Python 2.7 support will be dropped. |
Question: is there a package (similar to the pep8 module) that checks Python 2 code for compatibility with Python 3? I use Spyder as my primary editor and it provides helpful inline feedback when my code is not style compliant. |
It is probably best to not consider Python 2 at this point given the project's status. For example, this issue is far more important than considering backwards compatibility: labrad/scalabrad-web#331 @maffoo I think likely best to close this issue, thoughts? |
@jayich, I agree. Future development will be python3 only. |
Python 3 has nice asynchronous APIs. In order to keep the code python 2 compatible one has to use slightly less nice API's. For example, in python 2 no amount of compatibility libs can make this work:
I'm interested in working a bit on the python 3 back end so I'd like to know whether we want to have one back end that works for both python 2 and python 3.
The text was updated successfully, but these errors were encountered: