EuroPython 2017 - second part

Su­m­ma­ry of the last da­ys of ta­lks at Eu­ro­P­y­thon 2017, and the two da­ys fo­r s­prin­ts.

Thursday

The ke­y­no­te for this da­y, ti­tled The Di­ffe­rent Roads We Take, ma­de an in­te­res­ting point by sta­ting that the way we eva­lua­te our­sel­ves is no­n-­li­nea­r, and co­ming from di­ffe­rent ba­ck­groun­d­s, gi­ves eve­r­yo­ne of us di­ffe­rent a set of ex­pe­rien­ces and ski­ll­s.

Afte­rwar­d­s, I mo­ved to an ad­van­ced wo­rks­hop ca­lled A Han­d­s-on appro­ach to­ ­tu­ning Py­thon appli­ca­tions for per­for­man­ce, on whi­ch we co­ve­red se­ve­ra­l ­pro­fi­ling tools for Py­thon co­de, wi­th pros and cons of ea­ch one (per­for­man­ce, o­verhea­d, sim­pli­ci­ty of use), and so­me op­ti­mi­za­tion te­ch­ni­ques, run­ning the ­pro­fi­ling co­de after ea­ch im­pro­ve­ment was ma­de, in or­der to see the di­ffe­ren­ce.

Ri­ght be­fo­re lun­ch, the­re was an ad-hoc ses­sion of li­gh­tning ta­lks.

I al­so joi­ned an open ses­sio­n, on whi­ch we dis­cuss­ed the ro­le of co­ding an­d ­so­ftwa­re en­gi­nee­ring in edu­ca­tio­n.

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 ke­y­no­te for Fri­da­y, The En­coun­te­r: Py­tho­n’s ad­ven­tu­res in Afri­ca, wa­s ­min­d-­blo­win­g. It en­li­gh­te­ned many of us in the au­dien­ce, about is­sues we ­pro­ba­bly ha­ven’t even con­si­de­red be­fo­re, about Py­thon in a mu­ch broader sen­se as just a pro­gra­m­ming lan­gua­ge, dis­cus­sing it in the con­text of the ro­le of ­te­ch­no­lo­gy and in­no­va­tion in the pre­sent da­y.

Fo­llo­wing up wi­th the ta­lks Fin­ding bugs for free: The ma­gic of sta­ti­c a­na­l­y­sis, was a rea­lly ni­ce one. Afte­rwar­ds the­re was even an open ses­sio­n, on whi­ch we dis­cuss­ed the to­pic fur­the­r, on a mo­re con­cre­te fas­hion (by seein­g s­ta­tic ana­l­y­sis being do­ne on ac­tual pro­jec­ts, th­rou­gh 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 atten­ded one last ta­lk, Wri­ting Awe­so­me Py­PI pa­cka­ges in Py­thon, be­fo­re the ­li­gh­tning ta­lks and clo­sing ses­sio­n.

That was the end of the week for ta­lks, and wo­rks­hop­s, so the re­mai­ning ti­me was for sprin­ts.

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.