Python, en anmeldelse

Jeg er godt klar over at jeg er lidt sent ude, men jeg manglede en "smid-væk" opgave før jeg ville prøve Python.

For mange år siden fik min ven John Polstra lyst til at prøve Modula-3 og skrev et genialt værktøj kaldet "cvsup", der tillader replikering af et CVS repository over selv datidens meget tynde internetforbindelser, i mit tilfælde en 28.8kbit/s modem forbindelse.

Problemet var at "cvsup" ikke var en "smid-væk" opgave, det blev et instant-hit og derfor har portering af en modula-3 compiler været en af topprioriteterne for en ny FreeBSD platform i de sidste 10 år.

Lesson learned.

Jeg fik brug for at disassemblere noget m68k kode og besluttede at det var en god opgave at teste Python med ,der er helt sikkert tale om en engangsopgave.

Selvfølgelig kan man bare køre en m68k.bin fil igennem objdump(1), men hvis man har mulighed for at styre processen lidt og dumpe data-områder intelligent, så bliver kommer forståelsen noget hurtigere.

Som sagt så gjort, jeg brugte 16 timer på at skrive en m68k disassembler i Python 2.6.2 igår.

Umiddelbart finder jeg Pythons syntax noget rodet og nogle af ideerne, f.eks kolon efter strukturerende primitiver er ... primitive.

En syntax der er forskellig fra andre hovedsprog, bare for at være forskellig, er en dum ide.

Automatisk indrykning er derimod OK med mig.

Objektorientering i et sprog er meget bedre end objektorientering med et sprog, ikke nogen nyhed der, men jeg har ikke leget nok med klasser i python, til at vurdere kvaliteten, men de dele jeg brugte, virkede.

Jeg kunne særligt godt lide at Python har de gængse data-organisations primitiver indbygget, et nyt sprog der ikke har lister/køer og hash-tabeller fra starten, kommer mindst 25 år for sent.

Alt i alt, ikke noget ringe sprog, men heller ikke ligefrom vanedannende.

phk

Kommentarer (31)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kim Højgaard-hansen

Hej phk,

jeg savner lidt en sammenligning med et andet værktøj. Kunne du have gjort det hurtigere/bedre i noget andet?

Eller var Python trods nogen mangler "det rigtige værktøj til denne opgave" ?

Havde nok ikke regnet med at du ville være så relativt positivt omkring Python :)

  • 0
  • 0
Rene Nejsum

Jeg ved ikke hvad det er med Python, men det er det eneste sprog jeg programmere i, alene fordi det er sjovt.

Jeg startede med C, gik senere til Java, men har hele tiden haft Python på sidelinien, for også kunne nyde at kode.

Nu har jeg taget konsekvensen af det og startet et firma baseret på Python (og Django), jeg vil hellere have det sjovt hele tiden.

/Rene

  • 0
  • 0
Troels Liebe Bentsen

Python er jo ikke det eneste dynamisk sprog, du kan vælge imellem, jeg har selv prøvet at kode mindre og større ting i Perl, Python og Ruby. Og alle tre er en sand fornøjelse at kode i forhold til fx. statisk typede mainstream sprog som C#, Java og C++.

Selv er jeg faldet mest for Perl, dels på grund af CPAN: http://search.cpan.org/, Perl's modul/pakke arkiv som gør at man stort set aldrig skal starte for bunden, og dels fordi syntax'en er meget fri så man kan kode det som man vil(fx. du er ikke tvunget til at bruger Objekter hvis du ikke vil). Og sidste men ikke mindste DWIM("Do what i mean") ideen Perl er fantastisk så man ikke spilder sin tid med at type caste data typer, etc.

Desuden ligger mange af perl's indbyggede funktioner meget tæt på deres C udgave, så C kode er ofte ret nemt at "oversætte" til Perl.

  • 0
  • 0
Poul-Henning Kamp Blogger

Jeg ved ikke om opgaven egner sig til en egentlig sammenligning med andre sprog, den kunne principielt skrives i ethvert sprog hvor man kan læse en fil.

Jeg noterer mig at python virkede til opgaven, at de fleste af mine problemer skyldes ting python bare har valgt at gøre anderledes, uden egentlig at have en god grund til det.

Men ligefrem at sammenligne mit første forsøg på at skrive et program i Python med mine 25-30 års erfaring med andre sprog ville være useriøst.

Poul-Henning

  • 0
  • 0
Michael Rasmussen

Hej PHK og andre,

Min generelle holdning til Python er meget positiv, og specielt sprogets evne til dynamisk at loade moduler dynamisk, er jeg meget begejstret for. Se den inbyggede funktion import.

På et område adskiller Python sig dog fra de fleste andre programmer; nemlig anvendelsen af GIL (Great Interpreter Lock). GIL er katastrofalt, hvis man vil udvikle flertrådede programmer, og i særlig grad straffes man af GIL på flerkerne maskiner. En glimrende analyse kan læses her: http://www.dabeaz.com/python/GIL.pdf

  • 0
  • 0
Rene Nejsum

Det er ikke en glimerende analyse, det er en katastrofal analyse. Det beskrevne eksempel svarer til at tro at det er hurtigere at cykle 10 km i lige linie fra A til B ved at bruge to cykler, som man springer mellem for hver 100 m!

Hvis man skal sige noget kunne det være at den specifikke Python fortolker (cpython) kunne implementeres bedre på multicore maskiner.

Det er jo netop én af fordelene ved Python, mange firmaer (fx. Microsoft og Google) arbejder på at lave bedre fortolkere. Både Jython (Java) og IronPython (C#/.NET) performer væsentligt bedre end CPython (C) på mange områder, især ved meget store data set.

Jeg er dog enig med forfatteren af "analysen" at det er bedre at bruge besked-systemer end multitråde, men det er en anden snak.

  • 0
  • 0
Rasmus Morten Helbig Hansen

Det beskrevne eksempel svarer til at tro at det er hurtigere at cykle 10 km i lige linie fra A til B ved at bruge to cykler, som man springer mellem for hver 100 m!

Wtf? Det handler om at fordele identiske arbejdsbyrder mellem 2 CPUer vha tråde. Der er intet i arbejdsbyrden som lugter, men eksekveringstiden er den dobbelte.

bedre at bruge besked-systemer end multitråde

Forfatteren af artiklen kvalificerede det udsagn langt bedre. Det er ikke bedre.

Perl: enig, det er et write-only sprog

For hulan da kun når vi taler om golf. I de rette hænder er det et klart og tydeligt sprog.

  • 0
  • 0
Rene Nejsum

Med én CPU er det spild af tid at prøve at dele den beskrevne opgave op.

Som jeg også skrev er jeg er ikke i tvivl om at fortolkeren kunne implementeres bedre, også med henblik på multi core maskiner, men det har vel mindre med selve sproget at gøre.

Om besked systemer er bedre eller ej kræver nok mere end én fadøl at få afgjort, men jeg er personligt overbevist om at et sprog som fx. ABCL (alle objekter er tråde, alle metoder er beskeder) vil kunne implementeres både effektivt og interessant på noget moderne multicore hw.

Perl: Det er korrekt at i de rette hænder kan det skrives klart og tydeligt, men jeg har set maget perl kode der helt klart ikke er skrevet af de rette hænder.

  • 0
  • 0
Michael Rasmussen

Det beskrevne eksempel svarer til at tro at det er hurtigere at cykle 10 km i lige linie fra A til B ved at bruge to cykler, som man springer mellem for hver 100 m!

æhh, hvordan kommer du frem til den fortolkning? Hvis der skal flyttes to ton jord, må det forventes, at to personer kan gøre det hurtigere end en person. I Pythons tilfælde viser det sig, at tage længere tid for to personer at flytte et ton jord, end det gør for en person.

Hvis man skal sige noget kunne det være at den specifikke Python fortolker (cpython) kunne implementeres bedre på multicore maskiner

Det har intet med den specifikke fortolker at gøre, da GIL og GIL's indflydelse på trådede programmer, er en konsekvens af det grundliggende design i Python. Lige gyldig hvor god en fortolker du implementerer, vil din fortolker skulle opføre sig som cpython, og derved vil det ikke ændre på udsagnet: Trådimplementationen i Python er broken by design!

  • 0
  • 0
Rene Nejsum

Hvis man kun har én CPU har man kun én mand til at grave, han bliver ikke hurtigere færdig ved at tage én skovlfuld i hver bunke og bruge al tiden på at løbe frem og tilbage.

Jeg ved at folkene hos Microsoft der implementere IronPython ikke må se koden til CPython. De har derfor ikke implementeret GIL. Jeg vil derfor antage at IPy performer langt bedre på multicore.

  • 0
  • 0
James Avery

Jeg har svært ved at tro, du kan have mere end skimmet præsentationen. I hvert fald ser det ud som om, du har misforstået problemstillingen eftertrykkeligt.

Der beskrives flere problemer, men hovedsagen er, at CPU-bundne programmer tager betragtelig længere tid i Python med flere tråde, og især med flere CPU'er/kerner, end sekventielt. Altså ikke bare, at der ikke opnås speedup med flere kerner, men at programmer ligefrem kører absurd meget langsommere i "parallel". Dette gør tråde i Python praktisk talt nyttesløse.

Det er ikke sprogets skyld, men det at nuværende implementationer har en "Great Interpreter Lock", et design som nemt og elegant slår trådparallellitet ihjel for Python. Man kan sagtens skrive en Pythonfortolker uden, men som manden siger, så er det et stort projekt.

"Med én CPU er det spild af tid at prøve at dele den beskrevne opgave op."

Når den beskrevne opgave er at tælle til 10^8 to gange, giver det heller ikke mening at skrive et program til det. Svaret er 10^8 hver gang, og man kunne nøjes med at skrive "10^8" ned een gang for alle. Så var den sag klaret! Det ville dog være en sølle benchmark.

(At det kan tage 24.6 sekunder at tælle til 100.000.000 i en while-løkke siger nu heller ikke meget godt om fortolkerimplementationen!)

  • 0
  • 0
James Avery

"Det har intet med den specifikke fortolker at gøre, da GIL og GIL's indflydelse på trådede programmer, er en konsekvens af det grundliggende design i Python. Lige gyldig hvor god en fortolker du implementerer, vil din fortolker skulle opføre sig som cpython, og derved vil det ikke ændre på udsagnet: Trådimplementationen i Python er broken by design!"

Det vidste jeg ikke! Skyldes det en ualmindelig kortsynet specifikation, eller er semantikken simpelthen defineret som "sådan som CPython gør"?

Giver det ikke mening på et eller andet tidspunkt at bryde bagudkompatibilitet for at få fungerende tråde?

  • 0
  • 0
Michael Rasmussen

Skyldes det en ualmindelig kortsynet specifikation, eller er semantikken simpelthen defineret som "sådan som CPython gør"?

Det er ikke som sådan Python i sig selv, men den måde Guido ønsker fortolkeren implementeret på. Hans første prioritet er enkelttrådede programmer, og et sikkert afviklingsmiljø for extensions. Generelt er han stor modstander af låse, da det kan lede til dead-lock. Det bagvedliggende mantra er dog, for Guido, skal du afvikle kode parallelt, så afvikl det i flere processer.
http://www.artima.com/weblogs/viewpost.jsp?thread=214235
http://mail.python.org/pipermail/python-3000/2007-May/007414.html

  • 0
  • 0
Troels Liebe Bentsen

Perl: Det er korrekt at i de rette hænder kan det skrives klart og tydeligt, men jeg har set maget perl kode der helt klart ikke er skrevet af de rette hænder.

Jeg er sikker på at du også kan finde rigtig meget Python, Java, etc. slamkode uden at lede særligt længe. Men det er jo ikke det der gør et sprog dårligt eller godt. Bare fordi et sprog give dig nok snor til at hænge sig selv, behøver du jo ikke at gøre det.

Hvilket sprog jeg koder i handler om hvor godt det løser opgaven og om det er muligt at kode læseligt og vedligeholdelsesvænligt kode, og det er bestem ikke noget problem i Perl. Et hurtigt kig på CPAN vil også afsløre at det mest Perl kode faktisk er ret nemt at læse og vedligeholde. Min erfaring er også at de flest Perl udviklere både dokumentere og tester mere end hvad man typisk ser hos andre udvikler grupper. Så hvis man ikke kan lære at skrive gode Perl kode, så tvivler jeg på det går meget bedre i andre sprog.

Men igen er det jo en smags sag hvor meget man vil bindes på hænder og fødder ret syntaxmæssigt.

Og det kommer også an på opgaven hvad der passer bedste, fx. kan det være en fornøjelse at kode i både Python og Ruby hvis man kan gøre brug af et godt framework eller bibliotek der lige ligger til opgaven.

  • 0
  • 0
Troels Liebe Bentsen

På et område adskiller Python sig dog fra de fleste andre programmer; nemlig anvendelsen af GIL (Great Interpreter Lock). GIL er katastrofalt, hvis man vil udvikle flertrådede programmer, og i særlig grad straffes man af GIL på flerkerne maskiner.

Generelt er det en meget lille gruppe af programmer hvor GIL kommer i vejen, da man i langt de flest tilfælde kan løse samme opgave, med non-blocking/asynkron/event drevet kodningsteknikker, hvor man ikke løber ind i låse problematikker, delt hukommelse og andet snavs der gør det nemt at lave fejl. Min erfaring siger mig også at de er de færreste der faktisk kan kode tråde ordenligt.

Desuden har de flest sprog fine frameworks der kan overflødiggøre tråde til rigtig mange opgave, fx. har Python: http://twistedmatrix.com/trac/ og Perl IO::EventMux http://search.cpan.org/~tlbdk/IO-EventMux/ .

En anden fordel ved at kode på den måde er også at koden scalere uden af svine med hukommelsen. Fx er DJabberd er godt eksempel(kodet i Perl). http://www.danga.com/djabberd/

Og hvis du endeligt har noget der er beregningstungt, så kan man når langt med et par fork's. Du skal jo ikke bruge flere processer end du har CPU kerner.

  • 0
  • 0
Jesper Louis Andersen

Jeg ser ikke en manglende flertrådning som et problem nødvendigvis. For det første glemmer man at fokusere på det faktum at det er langt nemmere at lave en fortolker med en GIL. Derudover fungerer det fint så længe du ikke har brug for speedup.

Hvis man har brug for et speedup er der umiddelbart 2 løsninger: Kør flere python-processer eller endnu bedre: Vælg et sprog som faktisk er hurtigt. Til det første: Shared memory er død. Omkring 32 processorkerner går det galt. Så du skal alligevel bygge et system omkring at processer ejer data og så er threads døde. Til det andet: (c)Python er en bytekodefortolker. Og selv med projekter som pypy og unladen swallow er der ikke meget at komme efter fordi python mangler et typesystem.

  • 0
  • 0
Mikkel Jans

Jeg har brugt Python i lang tid nu. Man kommer ikke uden om det sprog, hvis man vil programmerer indenfor 3d film/tv.
Det som er forcen i Python er, ud over at være yderest flexibelt, have mange features og være produktivt at arbejde med, er det meget nemt at integrerer med C/C++.
Du kan kører C kode direkte inde i dit Python program, og der findes endda et sprog som er en blanding af python og C (Cython).
Det betyder at rigtig mange C-libraries også har en Python binding. Skulle ens program blive for langsomt, kan man konverterer de krævende dele til C. Selvom det nu aldrig har været nødvendigt for mig endnu.

Threads kan sagtens bruges, og gører programmet hurtigere, hvis de bliver brugt i de rigtige tilfælde. Ellers bør man anvende flere python-processer i stedet. multiprocessing modulet fungere meget godt til det.

Sammen med Qt, bliver det næsten For let at lave GUI's.

Jeg har det fint med GIL. Det er alligevel sjældent at program-hastighed har givet mig problemer, fordi det meste af tiden kalder man bare en underliggende C-function.
Det her program: http://www.youtube.com/watch?v=vFQTDPjy4sg
som jeg satte sammen på 2-3 uger, viser meget godt at man kan lave noget komplekst og CPU-krævende hurtigt i Python, ved at bruge eksisterende C-libraries.. Skulle det laves fra bunden i kun Python ville det selvfølelig tage meget længere tid, og være ubrugeligt langsomt. Men sådan noget gør man heller ikke i Python :).

  • 0
  • 0
Hans-Kristian Bjerregaard

Og her kommer vi ind til kernen i sagen. Et programmeringssprog er et værktøj så brug en hammer til dine søm og en skruetrækker til dine skuer. Og nej det er ikke smart at save med et brækjern.

Man skal ikke kunne alt i alle sprog og lige præcis pythons evne til at holde overordnet sammen på applikationer syntes jeg er den aller største fordel ved sproget. Nu større din applikation er desto større fordele får du af python.

  • 0
  • 0
Bob Hagenstrup

@Rene Nejsum:

"write-only sprog" er et underligt begreb. Det er 100% muligt at skrive et paent Perl program. Jeg ser ingen grund til at oversimplificere paa den maade.

Derudover skal siges at Perl er en del mere modent end naesten alle andre scriptingsprog, og performer (ifg mine tests) ofte bedre end Python (specielt til tekstbehandling, regex osv).

  • 0
  • 0
Rene Nejsum

Perl: Write-only tråden

Jeg så faktisk også engang et stykke assembler kode som jeg kunne læse, det var godt skrevet og godt dokumenteret, så ja naturligvis kan det lade sig gøre at skrive læsbar kode i alle sprog.

Det har helt sikkert også noget at gøre med hvor godt man er hjemme i sproget, men generelt siger min erfaring mig at sprog som Perl og Ruby hvor man kan udtrykke det samme på mange måder gør det unødvendig komplekst at læse andres kode.

Jeg har kodet i godt 20 år, vi er alle formet af vores historie og for mig har det været at Python passer mig godt. Hvis andre bliver glade af andre sprog er det fint med mig.

/rene

  • 0
  • 0
Anders Østergaard Jensen

Sjov, men positiv kommentar fra PHK vedr. Python. Af én eller anden grund havde jeg forventet noget old school mavegalde om, at "C is the only language", men den fordom bragte du vist til skamme med et brag. Godt gået, Poul-Henning. :)

Perl er bestemt ikke "write-only" i min bog. Problemet (eller fordelen?) er vel snarere den syntaktiske paradigme: At der er mange forskellige måder at gøre tingene på, og det giver dovne udviklere, som skriver doven kode. Jeg har set lige så mange pæne Perl-kildetekster, som jeg har set grimme og ulæselig Perl-kildetekster.

PHK: Jeg ser i øvrigt frem til dine kommentarer vedr. Ruby. Jeg foretrækker selv Ruby som scriptingsprog, særligt fordi det er lidt mindre syntaksrigidt end f.eks. Python -- dog uden at hælde mod Perls there is more than one way to do it-ekstremisme.

  • 0
  • 0
Brian Vinter

"GIL er katastrofalt, hvis man vil udvikle flertrådede programmer,"

Øhh - GIL er fantastisk når man udvikler flertrådede programmer fordi man med GIL slipper for en del låse som kan elimineres netop fordi GIL'en virker som en objekt-lås for (små) atomiske operationer (indrømmet det kræver god indsigt at udnytte det faktum).

Men det med flerkerne arkitekturer forstår jeg ikke, hvis du vil have høj hastighed så skriver du jo aligevel beregningsdelen i et andet sprog og GIL låses automatisk op når du kalder ud af Python så den kommer ikke i vejen (der er masser af HPC applikationer der bruger Python på den måde).

Og lad os så lige huske at tråde IKKE blev opfundet for parallelitet men for samtidighed, de af os der laver paralelle programmer foretrækker stadigt oftest processer fordi de giver os styr på heap allokeringen uden ekstra låse.

  • 0
  • 0
Lars Balker

PHK:

Perl: been there, done that

Det vil jeg godt betvivle.

God perl i dag ligner ikke god perl for 5 år siden, og da slet ikke som det så ud for 10 og 15 år siden.

I dag har vi Moose, det havde vi ikke før for 3 år siden. Dermed har vi nærmest har den stærkeste OO-model på denne side af BETA, CLOS og Smalltalk, og med lidt syntax sukker ovenpå (MooseX::Declare), næsten også den pæneste:

http://cpansearch.perl.org/src/FLORA/MooseX-Declare-0.23/t/recipes/basic...
http://cpansearch.perl.org/src/FLORA/MooseX-MultiMethods-0.03/t/game.t

chromatic har et glimrende blog-indlæg om vejen mod mere "Modern Perl" på http://www.modernperlbooks.com/

Udsagn som at perl er write-only er trættende i længden. Man kan skrive dårlig kode i mange sprog, nybegyndere skriver MEGET dårligt kode i vilkårlige sprog, og perl havde rigtigt mange nye programmører da CGI blev populært. Lidt som php det sidste årti...

  • 0
  • 0
Log ind eller Opret konto for at kommentere