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.


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.

Du­ring the after­noon, the­re we­re so­me in­te­res­ting ta­lks re­lated to clou­d ­com­pu­tin­g: Cloud Na­ti­ve Py­thon in Ku­ber­ne­tes, and Do­cke­ri­zed py­tes­ts. The ­for­mer ga­ve a su­perb in­tro­duc­tion to Ku­ber­ne­tes, whe­reas the la­tte­r, sho­wn a good ca­se for when to ha­ve the exact sa­me en­vi­ron­ment in de­ve­lo­p­ment and in ­the con­ti­nuous in­te­gra­tion (CI) ser­ve­r. This helps to mi­ni­mi­ze the effec­t of bug re­pro­du­ci­bi­li­ty, when ha­ving mul­ti­ples en­vi­ron­men­ts, spe­cia­lly fo­r ­pro­jec­ts that re­ly hea­vi­ly on the in­fras­truc­tu­re (if they ha­ve OS-­le­ve­l ­de­pen­den­cie­s, like li­bra­ries ins­ta­lle­d, and so on).

The­se ta­lks we­re rea­lly good, but I thi­nk the hi­gh­li­ght of the day wa­s Op­ti­mi­zing que­ries for not so big da­ta in Pos­tgreS­QL, whi­ch ac­tua­ll­y ­pre­sen­ted se­ve­ral wa­ys of op­ti­mi­zing que­ries on Pos­tgreS­QL, as we­ll as tip­s in or­der to iden­ti­fy bo­ttle­ne­cks, and per­for­man­ce is­sues. I liked the fact tha­t it had a mo­re con­cre­te appro­ach to per­for­man­ce tu­ning in da­ta­ba­ses, and even ­thou­gh it was ex­plai­ned for a lar­ge da­ta se­t, it sti­ll did­n’t make it “Bi­g ­Da­ta”, so it was a mo­re do­wn-­to­-ear­th ex­pla­na­tion wi­th real exam­ple­s, and tha­t a­dded a lot of va­lue.

La­ter on the da­y, after the ta­lks, the­re was a ses­sion for sprin­ts orien­ta­tio­n, on whi­ch all lea­ds brie­fly ex­plai­ned the pro­jec­ts they would be sprin­ting on. I ha­ve arri­ved wi­th the ex­pec­ta­tions of sprin­ting on CP­y­thon, but it was­n’­t ­pre­sen­te­d, and among all pre­sen­ted pro­jec­ts the one I got most in­te­res­ted in was py­py. At that point I de­ci­ded I was going to sprint on py­py.


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 ta­lks of the mor­ning Prac­ti­cal De­bu­gging - Tip­s, Tri­cks and Wa­ys ­to thi­nk, and Py­tho­nic Re­fac­to­rin­g: Pro­tec­ting Your Users From Chan­ge, ha­d ­ni­ce exam­ple­s, whi­ch le­ft me wi­th the idea of ex­plo­ring so­me of tho­se exam­ple­s a bit mo­re. In par­ti­cu­lar the la­tter one, men­tio­ned so­me co­m­mon pa­tterns in ­P­y­thon for evol­ving co­de that is al­ready pu­blis­hed un­der an API. I wi­ll ­co­ver so­me of the­se ideas in a fu­tu­re pos­t.

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.


Satur­da­y: As ex­pec­te­d, I joi­ned the py­py pro­jec­t. It was a great ex­pe­rien­ce ­to co­de along so many great (rea­lly grea­t) de­ve­lo­per­s. After a whi­le of se­ttin­g ­things up (clo­ning the re­po­si­to­r­y, ge­tting ac­quainted wi­th the co­de, plan­nin­g, and su­ch), I men­tio­ned that it would be in­te­res­ting to wo­rk on things that are s­ti­ll pen­ding for the Py­thon 3.6 su­ppor­t. Wi­th the help of the de­ve­lo­per­s we ported so­me mis­sing fea­tu­res added on the last ver­sion of Py­thon (a­ddin­g fs­pa­th func­tion to the po­sixos mo­du­le, in­clu­ding the new Mo­du­le­No­tFoun­dE­rror, and things like tha­t). It was hi­gh­ly pro­duc­ti­ve, an­d ­things see­med to wo­rk ni­ce­l­y.

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 rea­lly liked the pro­gress ma­de on py­py, and the pro­ject itsel­f. By co­din­g ­the­se is­sues, I learnt a lot about CP­y­thon itsel­f, mo­re to the point of its in­ter­nal com­po­nen­ts, and how things wo­rk. It was an awe­so­me sprin­t. Stay tu­ne­d ­for mo­re in­for­ma­tion abut chan­ges on py­py.