In moving toward python3, do we want to maintain backwards compatibility?

[DanielSank]

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:

async def a_coroutine(foo, bar):
    ...
    await another_coroutine(baz)

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.

[ejeffrey]

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.

[DanielSank]

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

[DanielSank]

http://trollius.readthedocs.io/deprecated.html

[ejeffrey]

Basically I think we should use trollius as a stepping stone. I don't
think porting to python 3 and asyncio and throwing out backwards
compatibility all at the same time is a good idea. So my suggestion is:

1. port to asyncio/trollius
2. Make python3 compatible (i.e., fix str unicode issues)
3. Once things are actually working with python 3, including servers, pyle,
   and any external dependencies, consider dropping python 2.7, and converting
   to native asyncio
4. free reign to use the cutting edge features of python 3.5+

I should point out that async def and await were only added last
september. Even people on python3 may still be on 3.4, although it is
nowhere near the barrier of the 2->3 transition.

On Sat, Jun 25, 2016 at 4:08 PM, Daniel Sank notifications@github.com
wrote:

http://trollius.readthedocs.io/deprecated.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#265 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABnKHKdhdbVi3CbrZTZwEUL8LGxO_1C_ks5qPbUKgaJpZM4I-Z0-
.

[DanielSank]

Yeah that makes sense. It's unfortunate that the Python 3 asynchronous APIs
keep changing..

On Jun 25, 2016 6:58 PM, "ejeffrey" notifications@github.com wrote:

Basically I think we should use trollius as a stepping stone. I don't
think porting to python 3 and asyncio and throwing out backwards
compatibility all at the same time is a good idea. So my suggestion is:

1. port to asyncio/trollius
2. Make python3 compatible (i.e., fix str unicode issues)
3. Once things are actually working with python 3, including servers, pyle,
   and any external dependencies, consider dropping python 2.7, and converting
   to native asyncio
4. free reign to use the cutting edge features of python 3.5+

I should point out that async def and await were only added last
september. Even people on python3 may still be on 3.4, although it is
nowhere near the barrier of the 2->3 transition.

On Sat, Jun 25, 2016 at 4:08 PM, Daniel Sank notifications@github.com
wrote:

http://trollius.readthedocs.io/deprecated.html

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#265 (comment),
or mute the thread
<
https://github.com/notifications/unsubscribe/ABnKHKdhdbVi3CbrZTZwEUL8LGxO_1C_ks5qPbUKgaJpZM4I-Z0-

.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#265 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AEX0CLujd2y0m_iMRQHDk-2IohK2apygks5qPdy3gaJpZM4I-Z0-
.

[jayich]

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

[DanielSank]

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 u/maffoo/python3 has a significant portion of that work already done.

[ejeffrey]

The biggest problem with porting to python 3 other than twisted
availability is the str/unicode split in python3. We generally thing this
is a good thing, but it requires changes to the labrad protocol and
examination of nearly every server setting.

To this end, we have already added the 'y' type for bYtes. Currently,
bytes is handled exactly the same way as 's', but the intend is to make 's'
a unicode string (sent with UTF-8 encoding). But we will need to go look
through every setting that takes a 's' type, decide if it should be 's' or
'y', and for 's' types, decide if it needs any unicode compatibility code.

All of this can be done easily in both python2 and 3, so it won't really
break backwards compatibility or require a lot of effort to maintain
python2 compatibility.

Most of the other changes are pretty simple and mechanical, like using
print_function. There will be a few issues with built-in functions that
now return generators instead of lists, but I don't expect that to be a big
problem, and it is always easy to fix.

On Mon, Jun 27, 2016 at 1:17 PM, jayich notifications@github.com wrote:

@ejeffrey https://github.com/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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#265 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABnKHOPSzCjKjwBBl3xeeiU0aIu-tIIHks5qQC_wgaJpZM4I-Z0-
.

[jwenner]

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.

[jayich]

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.

[jayich]

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?

[maffoo]

@jayich, I agree. Future development will be python3 only.