Programmering

Guido van Rossum trekker seg: Hva er neste for Python

Python-oppfinneren Guido van Rossum sjokkerte Python-verdenen 12. juli da han gikk av som språkets såkalte BDFL (velvillig diktator for livet). På den tiden siterte han akrimony over et nylig Python-forbedringsforslag for en språkuttrykkingsevne som motiverende for hans exit.

Men van Rossum, som oppfant Python i 1990, er fortsatt trygg på at språket vil fortsette helt fint uten hans ledelse. En hovedingeniør i Dropbox i sin daglige jobb, den 62 år gamle van Rossum snakket om hans beslutning om å gå videre med redaktør i Large Paul Krill.

: Hvorfor sa du opp som BDFL?

van Rossum: Livstidsdelen var selvfølgelig alltid en vits, som absolutt også diktaturdelen var. Jeg har lekt med tanken på pensjon, sannsynligvis den største delen av et tiår. Jeg har hatt noen helseproblemer, hvorav noen jeg trodde ble forverret av den kontinuerlige trusselen om alltid å være den mest ansvarlige personen i Python-samfunnet og måtte fortelle folk hvordan de skal gjøre ting og være stille og være rimelige og forklare språkets filosofi for den femte gangen.

Halmen som brøt kamelens rygg var et veldig omstridt Python-forbedringsforslag, der etter at jeg hadde akseptert det, gikk folk til sosiale medier som Twitter og sa ting som virkelig skadet meg personlig. Og noen av menneskene som sa skadelige ting, var faktisk kjerne-Python-utviklere, så jeg følte at jeg ikke lenger hadde tilliten til Python-kjerneutviklerteamet lenger.

: Forslaget var PEP (Python Enhancement Proposal) 572. Kan du snakke om fordelene med det forslaget og hvorfor det var så kontroversielt?

van Rossum: Forslaget handler om en ny syntaks som lar oppgaver skje som en del av uttrykksevalueringen. Det er alt i alt et ganske lite tillegg til språket. Det lar folk, når de føler behov, sette oppgaver midt i et uttrykk. Det er mange andre språk som har det som en mindre funksjon. Jeg er kjent med C og C ++. Så vidt jeg vet støtter Java og JavaScript det også. Det er en ganske nisje syntaks, men det kan i visse situasjoner gjøre koden lettere å skrive og også lettere å lese ved å fjerne overflødighet.

Mange følte at de visste hva Pythons designfilosofi var, og at dette forslaget ikke fulgte Pythons designprinsipper. Et annet problem med forslaget ble noe selvpåført av forslagsforfatterne. De første versjonene hadde noen alvorlige problemer. Disse problemene ble da årsaken til at folk, selv folk som var sympatiske med grunnideen, skulle stemme mot denne spesielle versjonen av forslaget. Det er en mindre syntaktisk endring. Det er ikke noe radikalt med det.

: Hvilken versjon av Python vil denne funksjonen være i?

van Rossum: Det vil være i Python 3.8, [som forfaller] om halvannet år.

: Blir det nok en BDFL? Hva blir styringsmodellen for Python fremover?

van Rossum: Dessverre kan jeg ikke fortelle deg at fordi jeg ga kjerneutviklergruppen - rundt 100 eller 200 personer som har forpliktet seg rettigheter eller i den siste tida hadde begått rettigheter - hjemmeleksene for å finne ut hva den nye styringsmodellen vil være og hvilke folk vil være i lade. Og de begynte umiddelbart å takle det problemet ettersom de takler andre problemer i Python-verdenen, som er med en lang diskusjon der forskjellige sider ikke umiddelbart kan komme til enighet.

Den eneste gode nyheten jeg har på dette tidspunktet er at de ble enige - jeg tror de var enige - om en tidsplan for å komme til en konklusjon her. Fristen for disse forslagene er 1. oktober 2018. Da tror jeg at innen 1. november 2018 er de forpliktet til å ha valgt et forslag til en styringsstruktur. Så innen 1. januar 2019 er de forpliktet til å faktisk ha valgt eller utnevnt, eller uansett hvordan styringsdokumentet sier, folket som skal ha ansvaret.

Hvis et av forslagene er, kommer det til å være en enkelt BDFL, må forslaget skrives opp i detalj, som hvordan BDFL er valgt og hvor lenge personen har ansvaret og hvordan han eller hun kan bli anklaget og alt at innen 1. oktober. Kanskje innen 1. januar vil de ha en faktisk person utnevnt.

: Hvem er noen av menneskene som er involvert i Pythons utvikling?

van Rossum: Det er en rekke kjerneutviklere som er mer vokal enn andre. En av de fineste gutta med en veldig lang track record er Brett Cannon. En annen person som har vært mentor for meg er en fyr som heter Tim Peters. Han er også forfatter av "The Zen of Python", som er et uformelt sett med retningslinjer for Python-utvikling. Barry Warszawa er også en av kjerneutviklerne.

: Hva vil ditt engasjement i prosjektet være fremover?

van Rossum: Jeg vil hoppe inn i rollen som en vanlig bidragsyter eller en vanlig kjerneutvikler. Jeg vil av og til skrive litt kode og gjennomgå kode. Jeg vil prøve å fokusere på å veilede kjerneutviklere, spesielt nye kjerneutviklere, spesielt kvinner og minoriteter fordi mangfold i kjerneutviklergruppen er et av mine mål.

: Er du bekymret for at avgangen din som BDFL kan skremme bort noen Python-hengivne?

van Rossum: Jeg tror ikke det. Python har et veldig sunt samfunn. Kjerneteamet har en veldig sunn dynamikk. Jeg hadde ikke sagt opp hvis jeg trodde at de ikke ville komme over dette og kunne lede språket fremover i flere tiår framover. Jeg vil si at dette er et lite hikke til tross for utseendet, og vi ser frem til meget vellykkede fremtidige utgivelser og en passende gradvis utvikling av utviklingsprosessen.

: Hvordan har utviklingen av Python utviklet seg de siste årene? Hvordan ser du det utvikle seg i fremtiden?

van Rossum: Språket endres åpenbart. Vi legger til noen nye funksjoner i språket, vi legger til noen nye funksjoner i biblioteket. Det store som har endret seg er sannsynligvis populariteten til språket. Inntil kanskje fem år siden følte Python seg som en ganske mindre spiller.

Siden den gang - sannsynligvis mest på grunn av den utrolige populariteten til datavitenskap og Python som det viktigste verktøyet for det - kan presset på kjerneutviklerne for å ha perfekte beslutninger ha økt, men måten ting generelt gjøres på, slik vi utvikler oss , og måten vi frigjør språket på har vært veldig stabil.

Vi har løslatelsesledere. Utgivelsene er omtrent halvannet år fra hverandre for store utgivelser. For feilrettingsutgivelser er de fra noen få måneder til kanskje tre fjerdedels år fra hverandre etter hvert som behovet oppstår.

Vi har den meget stabile Python-forbedringsforslagsprosessen. Kanskje måten PEP-er blir omgjort til punkter med stor uenighet har endret seg noe med økte nyheter om sosiale medier, men generelt, bortsett fra å bytte fra Mercurial til Git for noen år siden, har det vært en veldig stabil prosess, og det er ikke noe spesielt galt med den.

$config[zx-auto] not found$config[zx-overlay] not found