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

Version 1.0 - Released #312

Open
dabeaz opened this issue Feb 20, 2020 · 4 comments
Open

Version 1.0 - Released #312

dabeaz opened this issue Feb 20, 2020 · 4 comments

Comments

@dabeaz
Copy link
Owner

dabeaz commented Feb 20, 2020

I have released a version 1.0 of Curio. The overall core of the library is basically the same as before, but if you were using any its more experimental features, you might find them gone (sorry). This release also represents a general change in focus for the project. Early versions of Curio were very much about having a playground for trying out different ideas related to async programming. However, that experiment has now ended. Instead, the 1.0 release represents a desire to simply have a no-nonsense async library that's small, fast, and understandable. I'd also like it to be something stable that I can use in other projects.

I do not anticipate further major features being added to Curio. That said, I do intend to fix bugs and to maintain it so that it continues to work with new versions of Python. Thanks for your support.

@Tronic
Copy link

Tronic commented Feb 21, 2020

Is there a reason why you wouldn't just use Trio? It seems to have similar goals and everyone could benefit of a joint development effort in the already fragmented Python async world.

@nskalis
Copy link

nskalis commented Feb 21, 2020

thank you :) I am in love with curio

@dabeaz
Copy link
Owner Author

dabeaz commented Feb 21, 2020

Despite a similar name and the use of "await", Trio is not an embodiment of what I was trying to build with Curio. So no, I'm not especially interested in using it. I wrote Curio to be something that I would want to use as a programmer. If other people want to use it, that's fine. If not, that's also fine. The world is a big place.

@imrn
Copy link

imrn commented Feb 21, 2020

Is there a reason why you wouldn't just use Trio?

It's complicated. ;)

It seems to have similar goals and everyone could benefit of a
joint development effort in the already fragmented Python async world.

Did you ever mentioned this on trio issues or lists?

Some history: Trio project owner once had some 'sophisticated' async ideas
that could not find appropriate place in curio. So, he started his own
project. This is what you call fragmentation I guess.

It's still unclear whether those ideas created any value that worth
the hassle and complexity.

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

4 participants