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

EuroPython 2018 sprint #567

Closed
sorcio opened this issue Jul 25, 2018 · 6 comments
Closed

EuroPython 2018 sprint #567

sorcio opened this issue Jul 25, 2018 · 6 comments

Comments

@sorcio
Copy link
Contributor

sorcio commented Jul 25, 2018

Some Trio contributors (myself included) will be at EuroPython 2018 during the sprints session (Jul 28-29). We want to propose a Trio sprint to work on Trio itself and related projects. This is a perfect chance to:

  • work on open issues
  • get a friendly introduction to the Trio project itself
  • port your code to Trio
  • improve documentation and add tutorial examples
  • work on libraries in the Trio ecosystem (ASGI is a good example)

I'm opening this issue to track ideas and projects we will be working on. Also check open issues on the bug tracker, especially those labelled as "good first issue".

Feel free to comment and add ideas :)

Likely contributors:

Contributing guide to Trio and projects under the python-trio community: https://trio.readthedocs.io/en/latest/contributing.html

@njsmith
Copy link
Member

njsmith commented Jul 28, 2018

In addition to the issues labeled "good first issues", #542 (cleaning up our exports) might make a good first issue in a sprint setting – it hasn't been broken down into concrete steps yet so I hesitate to add the label, but at a sprint with some more experienced folk to provide guidance it could work, since the actual changes are going to be very straightforward I think.

Some of the things around the ecosystem that are on my mind:

  • Getting Trio support into urllib3/requests: for an overview of how we're approaching this, see RFC: what do you think of this branch adding async support to urllib3? urllib3/urllib3#1323. To contribute, the workflow is basically:

    • Check out the bleach-spike branch from this fork: https://github.com/python-trio/urllib3
    • Run the tests
    • Pick a failing test, or a skipped or xfailed test, and try to figure out how to fix it
    • Get lost and stuck because it's a big code base and there's a lot going on here
    • Ask for help
    • Repeat the last few steps until something works!
  • HTTP server support: talk to @Fuyukai about this I guess!

  • Adding some tests to cookiecutter-trio (Write some tests cookiecutter-trio#9) – it'd be great to publicize this more, but I'm nervous about doing so without some tests

  • Subprocess support: this is a much bigger thing to tackle (I would definitely recommend anyone just getting involved do something smaller first to get their feet wet!), but also a major blocker for lots of things. There's a summary of what's involved here: Subprocess support #4 (comment)

@njsmith
Copy link
Member

njsmith commented Jul 28, 2018

@pquentin points out that one pretty self-contained thing that needs doing on the urllib3 branch, and that might be a good place for someone to start if they're motivated and familiar with python in general but need some time to get up to speed on that project, would be to split out the source-code transformation plugin. Currently it lives inside setup.py in that branch, but really it should be a standalone project, so that other people can use it too by just importing it into their setup.py. And there's some other fairly straightforward maintenance that would also make sense, like writing some tests for the code transformation, and updating it to work on python 2.

(Making it work on python 2 is fairly straightforward: the code uses the tokenize module to break up Python source into tokens, and then iterates through applying certain rules to certain tokens, in particular the async and await tokens. On Python 3, tokenize classifies those tokens as being "keyword" tokens, while on python 2 they're plain "names". Or something like that. Right now the code only recognizes them if they're "keywords". But it would be pretty easy to relax this rule.)

[Edit: Apparently it is also broken on 3.7, due to other tokenizer changes... in fact maybe the same changes to fix it on 2.7 will also fix it on 3.7 and vice-versa?]

@sorcio
Copy link
Contributor Author

sorcio commented Jul 28, 2018

@monobot contributed first merged PR! #574 🎉 Thank you!

@monobot
Copy link
Contributor

monobot commented Jul 28, 2018 via email

@sorcio
Copy link
Contributor Author

sorcio commented Jul 31, 2018

I would like to extend a big thank you and welcome all contributors that took part in this sprint! The Trio world is enriched thanks to (in no particular order):

Not all above-mentioned work is complete, some is just a draft, a first proposal, or a successful experiment. All of it is a good amount of learning for everyone involved, and I think it gave great momentum to the project. If anything, it sparked a lot of enthusiasm in me! :)

@sorcio sorcio closed this as completed Jul 31, 2018
@njsmith
Copy link
Member

njsmith commented Aug 1, 2018

Thanks to all the participants, and especially the organizers, and especially especially @sorcio for writing this up!

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