7.1 Filinnlesing linje for linje

Åpner en tekstfil for lesing og gir deg et filobjekt som holder styr på hvor langt du har lest:

fil = open("medlemmer.txt")
linje = fil.readline()
print(linje)
fil.close()

Utskrift:

Ada 24

Legg merke til den tomme linjen i utskriften. Den kommer av at readline tar med linjeskiftet på slutten av linja, og print legger til ett til. Det er den første grunnen til at .rstrip() finnes.

Filnavnet er en helt vanlig tekst, og du kan bygge det med +:
serienavn + ".txt". Finnes ikke fila, stopper programmet, og siste linje i feilmeldingen er FileNotFoundError med filnavnet i.

Leser neste linje og gir den som en tekst, med linjeskiftet på slutten.

Filobjektet husker hvor du er. Første kall gir linje 1, andre kall gir linje 2, og så videre — du trenger ingen teller.

Er det ingen flere linjer igjen, gir readline den tomme teksten "". Det er signalet om at fila er slutt, og det er nettopp den verdien løkka bruker som stoppbetingelse.

En blank linje midt i fila gir "\n", ikke "". De to er ikke det samme, og det er derfor løkka ikke stopper for tidlig på en tom linje.

Malen for å hente feltene ut av en linje. Rens først, del så:

linje = "skrue;120;4\n" felt = linje.rstrip().split(";")
print(felt)
print(felt[0], felt[2])

Utskrift:

['skrue', '120', '4']
skrue 4

De to metodene leses fra venstre: .rstrip() gir en ny tekst uten linjeskiftet, og .split(";") deler den i en liste.

Uten argument deler .split() på blanktegn, som passer når feltene er skilt med mellomrom: "Ada 24".split() gir ['Ada', '24'].

Skilletegnet er en del av dataformatet, ikke noe du velger. Bruk det tegnet
fila faktisk bruker.

Noen filer har en overskriftslinje øverst som ikke er data. Løsningen er ett ekstra readline-kall før løkka:

fil = open("sykler.txt")
header = fil.readline()
print("Header:", header.rstrip())
linje = fil.readline()
antall = 0 while linje != "":
    antall = antall + 1 linje = fil.readline()
fil.close()
print("Datalinjer:", antall)

Utskrift:

Header: kode stativ turer
Datalinjer: 3

Det ene kallet «bruker opp» første linje, og løkka starter på linje 2. Du trenger ikke å ta vare på headeren; fil.readline() alene på en linje er nok.

Sjekk alltid om fila har en header før du koder. Har den det og du glemmer å
hoppe over den, prøver programmet å konvertere ordet turer til et tall, og stopper med ValueError: invalid literal for int() with base 10: 'turer'.

Filnavnet er en helt vanlig tekst og kan settes sammen med +:

navn = "Kolonier" filnavn = navn + ".txt" fil = open(filnavn)
linje = fil.readline()
antall = 0 while linje != "":
    antall = antall + 1 linje = fil.readline()
fil.close()
print(filnavn, "har", antall, "spillere")

Utskrift:

Kolonier.txt har 3 spillere

Formen navn + ".txt" er en gjenganger i settene: hvert objekt har sin egen fil, og navnet på objektet gir navnet på fila.

Punktumet og filendelsen må skrives inn selv — navn + "txt" gir Koloniertxt, og programmet stopper med FileNotFoundError.

En kortere form som gjør det samme som filinnlesing-løkka:

fil = open("medlemmer.txt")
for linje in fil:
    print(linje.rstrip())
fil.close()

Utskrift:

Ada 24
Nora 31
Per 19

Den er kortere og har ingen risiko for en uendelig løkke, siden det ikke finnes noen readline du kan glemme.

Boka bruker likevel while-formen som standard, av to grunner. Fagets egne
løsningsforslag skriver den, og den lar deg gjøre ting midt i lesingen — som å hoppe over en header eller å lese to linjer om gangen — som den korte formen ikke gjør like enkelt.

Kan du begge, er du trygg uansett hvilken form oppgaveteksten viser.

Lukker fila og frigjør den. Står etter løkka, aldri inne i den.

Lukker du fila inne i løkka, stopper programmet på neste readline, og siste linje i feilmeldingen er ValueError: I/O operation on closed file..

Glemmer du close helt, virker programmet som regel likevel — men det er en liten trekkfeil, og det er en dårlig vane i større programmer. Skriv den med én gang du har skrevet open, så glemmer du den ikke.

En fil som inneholder tegn, organisert i linjer skilt av linjeskift.

Den kan åpnes i en hvilken som helst editor, og det er nettopp derfor eksamensoppgaver bruker den: du kan se hva som står der, og du kan lage din egen testfil på ti sekunder.

Filer med bilder eller lyd er ikke tekstfiler og leses helt annerledes. De er ikke pensum her.

Det open(...) gir deg. Det er ikke innholdet i fila, men en forbindelse til den, med en usynlig markør for hvor langt du har lest.

Markøren er grunnen til at readline gir en ny linje hver gang uten at du trenger en teller.

Skal du lese den samme fila to ganger, må du åpne den på nytt. Markøren kan ikke spoles tilbake med de konstruksjonene som er pensum her.

Tegnet som avslutter en linje. I Python skrives det \n inne i en tekst, og det er ett tegn, ikke to.

Hver linje readline gir deg, har det på slutten — bortsett fra den aller siste linja i fila, hvis fila ikke slutter med en tom linje.

Du ser det aldri i en utskrift. Det viser seg bare som at teksten fortsetter på neste linje, eller som en ekstra tom linje når du skriver ut en urenset linje.

En blank linje midt i fila gir "\n", som ikke er den tomme teksten. Løkka stopper derfor ikke der, og det er riktig — en blank linje er data, ikke slutt.

Skriver du while linje.rstrip() != "": i stedet, stopper løkka på den første blanke linja. Det er sjelden det du vil.

Bokas faste mønster, i fem deler: open, første readline,
while linje != "":, kroppen, readline nederst — og close etter.

At readline står to steder, er det som ser rart ut første gang. Grunnen er at
while tester før hver runde, så den trenger en verdi allerede første gang.

Glemmer du den nederste, henger programmet. Det er den mest synlige feilen i hele kapitlet, og den letteste å rette.

En av bitene du får når du deler en linje: i "skrue;120;4" er "skrue",
"120" og "4" de tre feltene.

Feltene er alltid tekster, også når de ser ut som tall. Skal du regne med et
felt, må det gjennom int(...) — det er feilkode #4.

Rekkefølgen er fast og bestemt av dataformatet, så du henter dem med indeks.
Skriv gjerne én navngitt variabel per felt; det gjør besvarelsen lettere å rette.

Tegnet feltene er skilt med: semikolon, komma, kolon eller mellomrom.

Det er en del av dataformatet, ikke noe du velger. Bruker fila semikolon og du skriver .split(","), får du én stor bit i stedet for flere små — og feilen dukker opp langt unna, som en IndexError.

Er formatet uklart i en eksamensoppgave, skriv en kommentar om hvilket skilletegn du har forutsatt. Det er den ene legitime bruken av kommentarer i en besvarelse.

En overskriftslinje øverst i fila som ikke er data.

Hoppes over med ett ekstra fil.readline() før løkka. Du trenger ikke å ta vare på returverdien.

Glemmer du det, prøver programmet å konvertere et ord fra overskriften til et tall, og stopper med ValueError — med selve ordet i feilmeldingen. Ser du et overskriftsord der, vet du med én gang hva som mangler.

Formen er en gjenganger i settene: hvert objekt har sin egen fil, og navnet på objektet gir navnet på fila.

Punktumet må skrives inn selv. Og skal navnet komme fra en instansvariabel, skriver du self._tittel + ".txt" inne i metoden.

Mønsteret bak den faste fil-deloppgaven: lista opprettes før løkka, objektet lages av feltene inne i den, og lista returneres etter.

Tre plasseringer avgjør om det virker: samlingen over løkka, append
inne i den, return etter den.

Skal samlingen være en ordbok, byttes append med d[felt[0]] = obj, og alt annet står.

Varianten der du skal kunne slå opp på et navn eller en kode senere:
d[felt[0]] = Klasse(...).

Nøkkelen er som regel det første feltet, og verdien er hele objektet — ikke rådataen. Da beholder du tilgangen til objektets metoder.

En ordbok kan aldri ha to like nøkler. Har fila to linjer med samme navn,
overskrives den første uten en advarsel. Er det et problem, må oppgaven si
hva som skal skje.

Glemt int(...) eller float(...) på et felt.

Symptomene er to. Enten en TypeError når du prøver å regne med teksten — den snille varianten, som sier fra. Eller en sammenligning som svarer feil:
"9" > "10" er sann, fordi tekster sammenlignes tegn for tegn.

Den siste er stum og farlig. Konverter så snart feltet er hentet ut, ikke der du skal bruke det.

Glemt .rstrip() eller feil skilletegn.

Den rammer bare det siste feltet når det gjelder .rstrip(), og det gjør den ekstra lumsk: alt annet i programmet virker, og feilen dukker opp den dagen noen sammenligner det siste feltet med noe.

Motgiften er å skrive linje.rstrip().split(sep) som én fast lenke, hver gang, uten å vurdere om du «trenger» rensingen.

For en linje fra en fil er .rstrip() det riktige: det er linjeskiftet på slutten du vil bort med, og et mellomrom i starten kan være meningsfullt.

For et felt som kan ha fått et mellomrom rundt seg — for eksempel hvis fila er skrevet med "skrue ; 120" — er .strip() på hvert felt nyttig. Da renser du først linja, deler, og renser hvert felt.

Én funksjon som leser fila, én som regner på resultatet.

Det er slik oppgaveteksten som regel deler den også: «c) les fila og opprett objektene» og «d) skriv en metode som finner …».

Gevinsten på eksamen er konkret: du kan få full uttelling på den ene selv om du står fast på den andre. Og du kan bruke en metode oppgaven beskriver, uten selv å ha skrevet den.

Feilmeldingen når fila ikke finnes. Siste linje inneholder filnavnet, slik du skrev det.

De vanligste årsakene er en skrivefeil i navnet, en glemt .txt, eller at fila ligger i en annen mappe enn programmet.

På eksamen får du filnavnet oppgitt i teksten. Skriv det av tegn for tegn — også store og små bokstaver, som teller.

Den ene legitime bruken av kommentarer i en besvarelse: å dokumentere en antakelse når oppgaveteksten er underspesifisert.

I filoppgaver er det særlig tre ting: hvilket skilletegn du har forutsatt, om fila har en header, og hva du gjør med en linje som mangler et felt.

Én linje er nok: # forutsetter at filen ikke har overskriftslinje. Det viser at valget er bevisst, ikke tilfeldig.

Filobjektet husker hvor du er, så når løkka er ferdig, er fila «brukt opp».

Trenger du å gå gjennom dataene på nytt, er svaret nesten alltid å lagre dem i en liste eller ordbok ved første gjennomlesing, og så løpe gjennom samlingen så mange ganger du vil.

Det er også grunnen til at fil-deloppgaven kommer først i Oppgave 4: alle de senere deloppgavene jobber på samlingen, ikke på fila.

Formen der innlesingen er en metode på klassen, ikke en frittstående funksjon: def les_eiere(self): som fyller self._eiere.

Filnavnet bygges da av objektets egen instansvariabel:
open(self._tittel + ".txt").

Metoden returnerer som regel ingenting — den endrer objektet, og resultatet hentes med en aksessor etterpå. Det er en helt vanlig og riktig form i den store oppgaven.

To grunner: fagets egne løsningsforslag skriver den, og den lar deg gjøre ting midt i lesingen — hoppe over en header, lese to linjer om gangen, eller stoppe på en bestemt verdi.

Kan du begge, er du trygg uansett hvilken form oppgaveteksten viser. Og du kan alltid velge den korte når oppgaven bare ber om «gå gjennom alle linjene».

Ordboka husker den rekkefølgen nøklene ble opprettet i, ikke når de sist ble endret, og ikke etter størrelse.

Leser du fila ovenfra og ned, får ordboka nøklene i filas rekkefølge. Det er verdt å vite når du skal spore en utskrift av hele ordboka.

Skal noe sorteres, må det gjøres eksplisitt — og bokas stil er en eksplisitt finn-beste-løkke, ikke en ferdig sorteringsfunksjon.

Den faste plassen filbehandling har på eksamen: én deloppgave inne i den store modelleringen, verdt 5–10 poeng.

Bestillingen er nesten alltid «les fila og opprett objektene», og formatet oppgis i oppgaveteksten med et eksempel på et par linjer.

Skriv av eksempellinjen på kladdepapiret og marker skilletegnet og hvilket felt som er hva, før du koder. To minutter der sparer deg for begge halvdelene av feilkode #8.