EuroPython 2017 - second part

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


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.

Dur­ing the af­ter­noon, there were some in­ter­est­ing talks re­lat­ed to cloud ­com­put­ing: Cloud Na­tive Python in Ku­ber­netes, and Dock­er­ized pytests. The ­former gave a su­perb in­tro­duc­tion to Ku­ber­netes, where­as the lat­ter, shown a good case for when to have the ex­act same en­vi­ron­ment in de­vel­op­ment and in­ the con­tin­u­ous in­te­gra­tion (CI) serv­er. This helps to min­i­mize the ef­fec­t of bug re­pro­ducibil­i­ty, when hav­ing mul­ti­ples en­vi­ron­ments, spe­cial­ly for pro­jects that re­ly heav­i­ly on the in­fra­struc­ture (if they have OS­-level de­pen­den­cies, like li­braries in­stalled, and so on).

These talks were re­al­ly good, but I think the high­light of the day was Op­ti­miz­ing queries for not so big da­ta in Post­greSQL, which ac­tu­al­ly p­re­sent­ed sev­er­al ways of op­ti­miz­ing queries on Post­greSQL, as well as tip­s in or­der to iden­ti­fy bot­tle­neck­s, and per­for­mance is­sues. I liked the fact that it had a more con­crete ap­proach to per­for­mance tun­ing in databas­es, and even though it was ex­plained for a large da­ta set, it still did­n’t make it “Big ­Data”, so it was a more down-­to-earth ex­pla­na­tion with re­al ex­am­ples, and that added a lot of val­ue.

Lat­er on the day, af­ter the talk­s, there was a ses­sion for sprints ori­en­ta­tion, on which all leads briefly ex­plained the projects they would be sprint­ing on. I have ar­rived with the ex­pec­ta­tions of sprint­ing on CPython, but it was­n’t p­re­sent­ed, and among all pre­sent­ed projects the one I got most in­ter­est­ed in­ was pypy. At that point I de­cid­ed I was go­ing to sprint on pypy.


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 morn­ing Prac­ti­cal De­bug­ging - Tip­s, Tricks and Ways ­to think, and Python­ic Refac­tor­ing: Pro­tect­ing Your Users From Change, had nice ex­am­ples, which left me with the idea of ex­plor­ing some of those ex­am­ples a bit more. In par­tic­u­lar the lat­ter one, men­tioned some com­mon pat­terns in­ Python for evolv­ing code that is al­ready pub­lished un­der an API. I will ­cov­er some of these ideas in a fu­ture 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.


Sat­ur­day: As ex­pect­ed, I joined the pypy projec­t. It was a great ex­pe­ri­ence ­to code along so many great (re­al­ly great) de­vel­op­er­s. Af­ter a while of set­ting things up (cloning the repos­i­to­ry, get­ting ac­quaint­ed with the code, plan­ning, and such), I men­tioned that it would be in­ter­est­ing to work on things that are still pend­ing for the Python 3.6 sup­port. With the help of the de­vel­op­er­s we port­ed some miss­ing fea­tures added on the last ver­sion of Python (adding fs­path func­tion to the posixos mod­ule, in­clud­ing the new Mod­u­leNot­FoundEr­ror, and things like that). It was high­ly pro­duc­tive, and things seemed to work nice­ly.

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 re­al­ly liked the progress made on pypy, and the project it­self. By cod­ing these is­sues, I learnt a lot about CPython it­self, more to the point of it­s in­ter­nal com­po­nents, and how things work. It was an awe­some sprint. Stay tuned ­for more in­for­ma­tion abut changes on pypy.