Making a new release, using Python 3.6 features

[dabeaz]

At some point, I would like to make some kind of "stable" release for the current version of Curio and have that uploaded on PyPi. After that, I'd like to start taking advantage of new Python 3.6 features.

A couple of thoughts: A number of features such as asynchronous generators and expanded capabilities of async/await in Python 3.6 will be of direct benefit to Curio. I'd like to be able to use that. I'd also like to be to use things such as the new f-strings which are kind of cool.

One of the reasons why I've labeled Curio as highly "experimental" is that I've always viewed it as a forward-looking project with respect to usage of modern Python features. I don't really want to be perpetually locked into backwards compatibility at this early stage of the project.

In any event, I'm open to ideas. I don't really have any specific timeline in mind. I'm not inclined to start using Python 3.6 idioms until Python 3.6 is available more generally with things like the Anaconda distribution and so forth though. So, it wouldn't be right away.

[giampaolo]

+1, that would make version pinning in requirements.txt and setup.py a lot easier.

[imrn]

On 12/23/16, David Beazley notifications@github.com wrote:

I don't really want to be perpetually locked into backwards compatibility at this early stage of the project.

It's been 5-6 months I've been into Curio and ported all my previous async work on to it. It is interesting I've never encountered any breakage even if I get an 'git pull' every week or two.

I think Curio's fundamental api and functionality is in place. I wonder how would it be otherwise for the very fundamental building blocks such as socks, stream, threads, etc...

Given that situation is like this, Curio has already a big margin for an attitude you've put above.

[imrn]

Another point is that, I generally avoid to use any fancy stuff a library/platform/language provides. Making use of mostly the classical constructs provides a major flexibility: One can switch to another language/platform almost instantly.

For example, the greatest problem with asyncio was unnecessary inventions for the io. That kills portability.

On the otherhand deleting awaits (almost) in a Curio app gives you a runnable threaded sync code. That is if Curio disappears today, I can go back to pure sync code without much trouble.

Similarly most problematic thing for python its dynamic typing. As Curio is mostly built on it, this bothers me much. I take many defensive measures to block this creeping into my code.

Anyway this is me. Many may find above comments meaningless. However as you can notice, as I'm investing on any platform, first thing I would build is the exit gate..

At this point Curio may define its stance with respect to Python.

[njsmith]

I think using Python 3.6 features is a total non-issue. Everyone using curio now is by definition willing to jump through some hoops to keep things working, and by the time curio is actually stabilizing then 3.6 will be widespread.

I mean, maybe wait a week or two :-)

I think in a perfect world I'd like to see curio releasing to PyPI much more often. Yeah, things will break. That's what it says on the tin. The version of curio on PyPI right now is pretty much unusable (e.g. it doesn't propagate exceptions out of Kernel.run so you can't really write a working test suite). Unless you're planning to actually have a "stable release" in the sense of a guaranteed ABI for some time, backporting bug fixes, etc. -- which I think would be a bad idea at this stage! -- then I think the best model is just to release often, maybe on a timed schedule, and let people use version pinning to control their upgrade cycle.

[njsmith]

On further thought, I guess there is one scenario where sticking to py35 features might be worthwhile, and that's if PyPy manages to come up with a solid 3.5-compatible release and then there's a significant gap before they manage a 3.6-compatible release. But I think it probably isn't worth worrying about this until it happens? Worst case if it's really compelling we can always re-add 3.5 support when it comes up. I doubt backporting curio will ever be terribly difficult; f strings are handy but curio barely does any string formatting, and async generators are awesome but you can use them in 3.5 too at the cost of a tiny bit of extra syntactic noise.

[dabeaz]

A Python 3.5 version of PyPy would be quite interesting, but I'm not holding my breath waiting around for it (at least not in the context of Curio). Having some kind of Python 3.5 snapshot or Curio download would make it easier to test something like that when it happened though.

[njsmith]

Yeah, like I said, I wouldn't suggest holding your breath :-). FWIW, the current status, this email has some information on the current status of their efforts: https://mail.python.org/pipermail/pypy-dev/2016-December/014890.html (tl;dr: they have funding and are thinking they'll have something by summer).

[ghost]

@njsmith @dabeaz You can already try PyPy3 with Python 3.5 support. And https://mail.python.org/pipermail/pypy-dev/2016-December/014891.html yeah, putting 3.6 without 3.5 is not that smart.

[ghost]

Sadly, PyPy3.5 segfaults on running test suite: tests/test_subprocess.py::test_simple [1] 22911 segmentation fault (core dumped) python3 -m pytest But I can run simple examples just fine :) But speed improvements in current PyPy3.5 are not big. They'll be added in the next year

[dabeaz]

Just as a note: I have uploaded a Curio 0.5 release to PyPi that represents the current state of things as of today. Mainly this snapshot reflects a version of code that works with Python 3.5. I'd like to start taking advantage of Python 3.6 features going forward.

[ghost]

@dabeaz what python 3.6 features you'll use?

[dabeaz]

I'm thinking I might use all of them ;-). Of particular relevance to Curio might be async generators and comprehensions though.

[jkbbwr]

Can we release 0.6 on pypi also so that we have a frozen Python 3.5 version for curio as we are stuck on 3.5 in this project.

[dabeaz]

Yes. A 0.6 release should be made before jumping into Python 3.6.

[dabeaz]

A 0.6 release was made and is on PyPi. I've started including unit tests that utilize 3.6 features. So, I'd say it's fair game at this point.