EuroPython 2017 - second part

Sum­ma­ry of the last days of talks at Eu­roPy­thon 2017, and the two days for sprints.

Thursday

The key­note for this day, ti­tled The Dif­fer­ent Roads We Take, made an in­ter­est­ing point by stat­ing that the way we eval­u­ate our­selves is non-­lin­ear, and com­ing from dif­fer­ent back­ground­s, gives ev­ery­one of us dif­fer­ent a set of ex­pe­ri­ences and skill­s.

Af­ter­ward­s, I moved to an ad­vanced work­shop called A Hand­s-on ap­proach to tun­ing Python ap­pli­ca­tions for per­for­mance, on which we cov­ered sev­er­al pro­fil­ing tools for Python code, with pros and cons of each one (per­for­mance, over­head, sim­plic­i­ty of use), and some op­ti­miza­tion tech­niques, run­ning the pro­fil­ing code af­ter each im­prove­ment was made, in or­der to see the dif­fer­ence.

Right be­fore lunch, there was an ad-hoc ses­sion of light­ning talk­s.

I al­so joined an open ses­sion, on which we dis­cussed the role of cod­ing and soft­ware en­gi­neer­ing in ed­u­ca­tion.

During the afternoon, there were some interesting talks related to cloud computing: Cloud Native Python in Kubernetes, and Dockerized pytests. The former gave a superb introduction to Kubernetes, whereas the latter, shown a good case for when to have the exact same environment in development and in the continuous integration (CI) server. This helps to minimize the effect of bug reproducibility, when having multiples environments, specially for projects that rely heavily on the infrastructure (if they have OS-level dependencies, like libraries installed, and so on).

These talks were really good, but I think the highlight of the day was Optimizing queries for not so big data in PostgreSQL, which actually presented several ways of optimizing queries on PostgreSQL, as well as tips in order to identify bottlenecks, and performance issues. I liked the fact that it had a more concrete approach to performance tuning in databases, and even though it was explained for a large data set, it still didn’t make it “Big Data”, so it was a more down-to-earth explanation with real examples, and that added a lot of value.

Later on the day, after the talks, there was a session for sprints orientation, on which all leads briefly explained the projects they would be sprinting on. I have arrived with the expectations of sprinting on CPython, but it wasn’t presented, and among all presented projects the one I got most interested in was pypy. At that point I decided I was going to sprint on pypy.

Friday

The key­note for Fri­day, The En­coun­ter: Python’s ad­ven­tures in Africa, was mind-blow­ing. It en­light­ened many of us in the au­di­ence, about is­sues we prob­a­bly haven’t even con­sid­ered be­fore, about Python in a much broad­er sense as just a pro­gram­ming lan­guage, dis­cussing it in the con­text of the role of tech­nol­o­gy and in­no­va­tion in the present day.

Fol­low­ing up with the talks Find­ing bugs for free: The mag­ic of stat­ic anal­y­sis, was a re­al­ly nice one. Af­ter­wards there was even an open ses­sion, on which we dis­cussed the top­ic fur­ther, on a more con­crete fash­ion (by see­ing stat­ic anal­y­sis be­ing done on ac­tu­al pro­ject­s, through the tool lgtm).

The last two talks of the morning Practical Debugging - Tips, Tricks and Ways to think, and Pythonic Refactoring: Protecting Your Users From Change, had nice examples, which left me with the idea of exploring some of those examples a bit more. In particular the latter one, mentioned some common patterns in Python for evolving code that is already published under an API. I will cover some of these ideas in a future post.

I at­tend­ed one last talk, Writ­ing Awe­some PyPI pack­ages in Python, be­fore the light­ning talks and clos­ing ses­sion.

That was the end of the week for talk­s, and work­shop­s, so the re­main­ing time was for sprints.

Sprints

Saturday: As expected, I joined the pypy project. It was a great experience to code along so many great (really great) developers. After a while of setting things up (cloning the repository, getting acquainted with the code, planning, and such), I mentioned that it would be interesting to work on things that are still pending for the Python 3.6 support. With the help of the developers we ported some missing features added on the last version of Python (adding fspath function to the posixos module, including the new ModuleNotFoundError, and things like that). It was highly productive, and things seemed to work nicely.

Sunday: Another day to sprint on pypy! This time, we pair-programmed into trying to port the asyncio functionality. Part of this was being done the day before (I didn’t took that much of part, as I was starting with the other issues — but this time I wanted to contribute). It was basically trying to fix the way asynchronous generators work on several scenarios (when calling different methods on them, like .asend(), .athrow(), etc.). Here I mainly added unit tests for these scenarios, in order to check that pypy works the same as CPython for some of these common scenarios (which are still not fully covered, but a great progress was made).

I really liked the progress made on pypy, and the project itself. By coding these issues, I learnt a lot about CPython itself, more to the point of its internal components, and how things work. It was an awesome sprint. Stay tuned for more information abut changes on pypy.