Python-opfinderen Guido van Rossum chokerede Python-verdenen den 12. juli, da han trådte tilbage som sprogets såkaldte BDFL (velvillig diktator for livet). På det tidspunkt citerede han akrimonisme over et nyligt Python-forbedringsforslag til en sprogudtryks evne som motiverende for hans exit.
Men van Rossum, der opfandt Python i 1990, er fortsat overbevist om, at sproget fortsætter helt fint uden hans ledelse. En hovedingeniør hos Dropbox i sit daglige job, den 62-årige van Rossum talte om sin beslutning om at gå videre med redaktør hos Large Paul Krill.
: Hvorfor fratrådte du som BDFL?
van Rossum: Livstidsdelen var naturligvis altid en vittighed, som diktaturets del bestemt også var. Jeg har leget med tanken om pensionering sandsynligvis den største del af et årti. Jeg har haft et par helbredsproblemer, hvoraf nogle troede jeg blev forværret af den kontinuerlige trussel om altid at være den mest ansvarlige person i Python-samfundet og skulle fortælle folk, hvordan man gør ting og bliver stille og er rimelig og forklarer sprogets filosofi for den femtende gang.
Halmen, der brækkede kamelens ryg, var et meget omstridt Python-forbedringsforslag, hvor folk, efter at jeg havde accepteret det, gik til sociale medier som Twitter og sagde ting, der virkelig skadede mig personligt. Og nogle af de mennesker, der sagde sårende ting, var faktisk centrale Python-udviklere, så jeg følte, at jeg ikke helt havde tilliden til Python-udviklerholdet mere.
: Forslaget var PEP (Python Enhancement Proposal) 572. Kan du tale om fordelene ved dette forslag, og hvorfor det var så kontroversielt?
van Rossum: Forslaget handler om en ny syntaks, der lader opgaver opstå som en del af udtryksvurderingen. Det er alt i alt en ret mindre tilføjelse til sproget. Det lader folk, når de føler behov, sætte opgaver midt i et udtryk. Der er mange andre sprog, der har det som en mindre funktion. Jeg er fortrolig med C og C ++. Så vidt jeg ved, understøtter Java og JavaScript det også. Det er et temmelig niche syntaks, men det kan i visse situationer gøre koden lettere at skrive og også lettere at læse ved at fjerne overflødighed.
Mange mennesker følte, at de vidste, hvad Pythons designfilosofi var, og at dette forslag ikke fulgte Pythons designprincipper. Et andet problem med forslaget var noget selvforskyldt af forslagsforfatterne. De første få versioner havde nogle alvorlige problemer. Disse problemer blev derefter grunden til, at folk, selv folk, der var sympatiske med den grundlæggende idé, stemte imod netop denne version af forslaget. Det er en mindre syntaktisk ændring. Der er ikke noget radikalt ved det.
: Hvilken version af Python vil denne funktion være i?
van Rossum: Det vil være i Python 3.8, [som skyldes] om halvandet år.
: Vil der være endnu en BDFL? Hvad vil styringsmodellen for Python være fremadrettet?
van Rossum: Desværre kan jeg ikke fortælle dig, at fordi jeg gav kerneudviklergruppen - nogle 100 eller 200 mennesker, der har forpligtet sig til rettigheder eller i den seneste tid havde forpligtet sig til rettighederne - hjemmearbejdet med at finde ud af, hvad den nye styringsmodel vil være, og hvilke mennesker der vil være oplade. Og de begyndte straks at tackle dette problem, da de tackler ethvert andet problem i Python-verdenen, hvilket er med en lang diskussion, hvor forskellige sider ikke straks kan nå til enighed.
Den eneste gode nyhed, jeg har på dette tidspunkt, er, at de var enige - jeg tror de var enige - om en tidsplan for at nå frem til en konklusion her. Fristen for disse forslag er den 1. oktober 2018. Så tror jeg, inden den 1. november 2018 er de forpligtet til at have valgt et forslag til en styringsstruktur. Senest den 1. januar 2019 er de forpligtet til faktisk at have valgt eller udnævnt, eller uanset hvad deres regeringsdokument siger, de mennesker, der skal have ansvaret.
Hvis et af forslagene er, vil der være en enkelt BDFL, skal forslaget skrives op i detaljer, ligesom hvordan BDFL er valgt, og hvor længe personen forbliver ansvarlig, og hvordan han eller hun kan anklages og alt at inden 1. oktober. Måske inden den 1. januar får de en faktisk person udnævnt.
: Hvem er nogle af de mennesker, der er involveret i Pythons udvikling?
van Rossum: Der er en række kerneudviklere, der er mere vokal end andre. En af de bedste fyre med en virkelig lang track record er Brett Cannon. En anden person, der har været mentor for mig, er en fyr ved navn Tim Peters. Han er også forfatter til "The Zen of Python", som er et uformelt sæt retningslinjer for Python-udvikling. Barry Warszawa er også en af kerneudviklerne.
: Hvad vil din involvering i projektet være fremad?
van Rossum: Jeg springer ind i rollen som en almindelig bidragsyder eller en almindelig kerneudvikler. Jeg vil lejlighedsvis skrive noget kode og gennemgå kode. Jeg vil forsøge at fokusere på at vejlede kerneudviklere, især nye kerneudviklere, især kvinder og mindretal, fordi mangfoldighed i kerneudviklergruppen er et af mine mål.
: Er du bekymret for, at din afgang som BDFL måske skræmmer nogle Python-hengivne væk?
van Rossum: Jeg tror ikke det. Python har et meget sundt samfund. Kerneteamet har en meget sund dynamik. Jeg ville ikke have trukket mig tilbage, hvis jeg troede, at de ikke ville komme over dette og være i stand til at guide sproget fremad i årtier fremover. Jeg vil sige, at dette er en mindre hikke på trods af udseendet, og vi ser frem til meget vellykkede fremtidige udgivelser og en passende gradvis udvikling af udviklingsprocessen.
: Hvordan har Python-udviklingsprocessen udviklet sig i de sidste par år? Hvordan kan du se det udvikle sig i fremtiden?
van Rossum: Sproget ændres naturligvis. Vi tilføjer nogle nye funktioner til sproget, vi tilføjer nogle nye funktioner til biblioteket. Den store ting, der har ændret sig, er sandsynligvis sprogets popularitet. Indtil måske for fem år siden følte Python sig som en temmelig mindre spiller.
Siden da - sandsynligvis for det meste på grund af den utrolige popularitet af datalogi og Python som det vigtigste redskab til det - kan presset på kerneudviklerne til at have perfekte beslutninger muligvis gået op, men den måde, tingene generelt gøres på, den måde, vi udvikler på , og den måde, vi frigiver sproget på, har været meget stabil.
Vi har frigørelsesledere. Udgivelserne er cirka halvandet år fra hinanden for større udgivelser. For frigivelser af fejlrettelser har de et par måneder til måske tre fjerdedele af året fra hinanden, når behovet opstår.
Vi har den meget stabile Python-forbedringsforslagsproces. Måske har den måde, hvorpå PEP'er omdannes til punkter med stor uenighed, ændret sig noget med øgede nyheder om sociale medier, men generelt har det bortset fra at skifte fra Mercurial til Git for nogle få år siden været en meget stabil proces, og der er ikke noget særligt galt med det.
