ProgrammeringsBaren! Småprat, om det du elsker!

[sindreij]

Har desverre ikke sjekket programmet ditt, men det kan være et klassisk eksempel på hvilken galskap det er å bruke et diktatorspråk som forandrer semantikken plutselig fra en versjon til en annen:

 

Forskjellen er at / i python2 er heltallsdivisjon, mens det i python3 er vanlig divisjon

Python2:

>>> 3/2
1

python3:

>>> 3/2
1.5 

 

Dette er en kjærkommen oppdatering siden det siste er mye mer logisk. Gjør du som GeirGrusom sier, blir det riktig (dvs som i python3) uansett.

 

Det å si at python er et:

diktatorspråk som forandrer semantikken plutselig fra en versjon til en annen

blir for drøy. For det første er dette første gangen python endrer en del ting som ikke er bakoverkompatible. For det andre er denne endringen varslet lenge før python 3.0 kom ut, i tillegg til at python har utivklet to versjoner ved siden av hverandre lenge. Din lokale atomreaktor kan bruke python2.7 i mange år til, og fremdeles få support. Når tiden er inne til å oppgradere til python3 finnes det mye dokumentasjon på nøyaktig hva som er endret, i tillegg til et script som gjør om ting som print "abc" til print("abc")

Endret 23. september 2011 av sindreij

[Matsemann]

Jeg er enig i det ang. oppdateringen. Å skulle beholde bakoverkompatabilitet hele tiden hindrer en i å kunne fornye seg. Samtidig gjør det folk late når det kommer til nye versjoner. Merket spesielt dette når PHP gikk fra versjon 4 til 5. Mye av det gamle var fortsatt i veien for det nye. Samtidig som koden ble en salig blanding av nytt og gammelt mange plasser.

 

Uansett, så lenge man faktisk ikke selv bestemmer datatype i Python bør den dele med desimaltall. Kan være litt "magisk" når tallet ditt plutselig tolkes som et heltall o.l.

 

I Python 2.7 kan man forøvrig gjøre slik:

>>> 1/2

0

>>> 1/2.0

0.5

>>> from __future__ import division

>>> 1/2

0.5

>>> 1//2

0

>>> 1//2.0

0.0

 

Da er / desimal, og // tvinger til heltalldivisjon selv med desimaltall.

[asicman]

Forskjellen er at / i python2 er heltallsdivisjon, mens det i python3

er vanlig divisjon

 

Jeg er fullstendig klar over det. Det var derfor jeg kodet eksemplet mitt akkurat slik. Jeg har også vært inne på det samme i en tidligere melding:

 

https://www.diskusjon.no/index.php?showtopic=800754&p=15915217&st=940entry15915217

 

 

 

Det å si at python er et:

diktatorspråk som forandrer semantikken plutselig fra en versjon til en annen

blir for drøy. For det første er dette første gangen python endrer en del ting som ikke er bakoverkompatible. For det andre er denne endringen varslet lenge før python 3.0 kom ut, i tillegg til at python har utivklet to versjoner ved siden av hverandre lenge. Din lokale atomreaktor kan bruke python2.7 i mange år til, og fremdeles få support. Når tiden er inne til å oppgradere til python3 finnes det mye dokumentasjon på nøyaktig hva som er endret, i tillegg til et script som gjør om ting som print "abc" til print("abc")

 

 

Det hjelper lite dersom f.eks. et library ble skrevet lenge før endringen ble varslet eller t.o.m. påtenkt av Guido. Dette library kan bli brukt i et program og fungere i årvis. Så oppgraderer man til 3.0 fordi man gjerne ville bruke et annet library som er skrevet for Python 3.0. Programmet virker like fint i flere år, inntil f.eks. en listelengde som var even plutselig ble odd igjen og programmet krasjer. De som drifter atomreaktoren vet ikke at dette er et problem i det underliggende library engang.

 

Man kan hevde at testingen var for dårlig, og de som drifter en atomreaktor har forhåpentligvis krav til testdekning osv. Men det å endre semantikk slik kan være katastrofalt. Det hadde nesten vært bedre om man introduserte en ny syntax.

 

 

i tillegg til et script som gjør om ting som print "abc" til print("abc")

 

I Gentoo er desverre pakkesystemet (portage) skrevet i Python. Man har et program som heter python-updater som hacker på Python code. Google for python-updater og problems så ser du at dette ikke alltid er helt problemfritt. Man har også en perl-cleaner for å rydde opp etter en annen diktator.

 

Det er komplisert nok å sloss mot library avhengigheter om man ikke skal få problemer med at semantikken plutselig endres.

 

Men la oss håpe disse problemene forvitrer så raskt som mulig og man konvergerer i mot noe som er mer stabilt.

[Dipol]

Tror python driver en prank mot meg.

 

Jeg skriver

import datetime
dt=datetime.date(1990,08,22) # Får SyntaxError: invalid token
dt=datetime.date(1990,07,22) # Får ikke feilmelding ? 

 

Noen som kan forklare? Hvorfor fungerer 07, men ikke 08 ?

 

EDIT: 09 fungerer heller ikke, men 10 fungerer ? Jeg bruker python 2.7

Endret 23. september 2011 av Dipol

[GeirGrusom]

2 er et heltall. Det er ikke et flyttall, og jeg synes ikke at haltall delt på heltall skal bli flyttall med mindre en faktisk ber om det. Å legge til en egen operatør for heltallsdivisjon (slik som \ i Visual Basic) burde ikke være nødvendig.

For meg er det forvirrende om divisjon av heltall blir til flyttall, fordi det i essens betyr at runtimen latterligjør intelligensen min. Her sitter jeg og adderer, subtraherer og multiplisererer heltall uten problemer, men når jeg plutselig dividerer, så er resultatet et flyttall? Hvor ble det av de herlige, effektive heltallene mine?

[asicman]

 

>>> from __future__ import division

 

 

Det hjelper lite dersom det tenkte library var skrevet før denne future egenskapen ble implementert, men det kan hjelpe de som skriver kode etter man blir klar over at diktatoren vil gjøre en slik endring.

[Matsemann]

Tror python driver en prank mot meg.

 

Jeg skriver

import datetime
dt=datetime.date(1990,08,22) # Får SyntaxError: invalid token
dt=datetime.date(1990,07,22) # Får ikke feilmelding ? 

 

Noen som kan forklare? Hvorfor fungerer 07, men ikke 08 ?

 

EDIT: 09 fungerer heller ikke, men 10 fungerer ? Jeg bruker python 2.7

Legger du 0 foran tolkes det som octal. Skriv 1, 2, .., 7, 8, 9 osv.

Grunnet til opp til 07 går er jo det blir det samme i octal som vanlig.

^den setningen ble rar, prøver på nytt

Det går med de lave tallene, side 06 (oct) = 6 dec

Derimot vil 08 (oct) ikke eksistere.

Endret 23. september 2011 av Matsemann

[Matsemann]

2 er et heltall. Det er ikke et flyttall, og jeg synes ikke at haltall delt på heltall skal bli flyttall med mindre en faktisk ber om det.

Men har du uflaks i Python er jo plutselig flyttallet ditt et heltall.

[GeirGrusom]

2 er et heltall. Det er ikke et flyttall, og jeg synes ikke at haltall delt på heltall skal bli flyttall med mindre en faktisk ber om det.

Men har du uflaks i Python er jo plutselig flyttallet ditt et heltall.

Jeg trodde Python var sterkt typet? Virker ikke sånn.

[asicman]

>>> x=3
>>> type(x)
<class 'int'>
>>> x/=2
>>> type(x)
<class 'float'>
>>> x=math.ceil(x)
>>> type(x)
<class 'int'>
>>> x="four"
>>> type(x)
<class 'str'>

[x871kx6167ss7]

Må si jeg synes scheme sin løsning når det kommer til tall er blandt de bedre (det er inspirert av Common Lisp). I scheme så har man et numerisk tårn: integers, rationals, reals og complex. Også er det slik at dersom et tall er en integer, så er det også et rational. Og dersom det er rational, så er det også en real. Og reals er compex.

 

Med andre ord "etterapes" de mattematiske mengdene med .

 

I tillegg så skilles det mellom eksakte og ueksakte tall. Også er det sånn at dersom man utfører en av de grunnlegende operasjonene (som +, -, * osv) på to eksakte tall, så får du et eksakt svar, mens dersom en av argumentene er ueksakte, så blir svaret (sansynlig vis) ueksakt. Dersom en beregning bare er basert på eksakte tall og eksakte operasjoner, så skal resultatet også bli "matematisk korrekt".

 

2 er et heltall. Det er ikke et flyttall, og jeg synes ikke at haltall delt på heltall skal bli flyttall med mindre en faktisk ber om det.

Men har du uflaks i Python er jo plutselig flyttallet ditt et heltall.

Jeg har ikke så mye erfaring med python, men synes det høres rart ut at et flyttall kan være et heltall i python. Kan du gi et eksempel eller utdype?

[snippsat]

De som drifter atomreaktoren vet ikke at dette er et problem i det underliggende library engang.

Dem vet sikkert at skal man ha eksakte kalulasjoner bruker man Decimal module

Nå er "Floating-Point Arithmetic" probematikken likt for de fleste språk.

What Every Computer Scientist Should Know About Floating-Point Arithmetic

Nå diskutere vi teamet rundt side 48,49,... i denne posten.

 

Jeg trodde Python var sterkt typet? Virker ikke sånn.

Python sterk typet ja.

Uten og gå noe mer inn på det er det bra forklart Why is Python a dynamic language and also a strongly typed language

Endret 23. september 2011 av SNIPPSAT

[asicman]

De som drifter atomreaktoren vet ikke at dette er et problem i det underliggende library engang.

Dem vet sikkert at skal man ha eksakte kalulasjoner

 

De kan bruke et underliggende bibliotek som de ikke har skrevet selv og ikke har fullstendig oversikt over. Dette kan ha benyttet seg av en egenskap i språket: at heltallsdivisjon er trunkerende og gir et heltall til svar.

 

Heltall gir entydige svar innenfor den semantikken som var angitt, f.eks. til å beregne indekser i arrayer osv. f.eks. GeirGrusom sier

 

 

Hvor ble det av de herlige, effektive heltallene mine?

 

Han forventer helt klart denne semantikken som finnes i C, Java, osv. og som fantes i Python fram til 2.7, men som plutselig ble endret.

 

 

Heldigvis vil de fleste programmer få runtime feil grunnet dette og at koden da endres. F.eks. vil dette virke under Python 2.7 og krasje under Python 3.0

 

import sys
from datetime import date

idx=date.today().year-2000
idx/=3
myencryptionkey="supersecret"
sys.stdout.write("magic is " + myencryptionkey[idx:] + "\n")

[asicman]

Jeg har ikke så mye erfaring med python, men synes det høres rart ut at et flyttall kan være et heltall i python. Kan du gi et eksempel eller utdype?

 

Python ser ikke ut til å ha et type-hierarki som mange andre språk, f.eks:

 

Python 3:

 

>>> isinstance(2,int)
True
>>> isinstance(2,float)
False
>>> isinstance(2/3,int)
False
>>> isinstance(2/3,float)
True

 

Ptyhon 2.7

 

>>> isinstance(2,int)
True
>>> isinstance(2,float)
False
>>> isinstance(2/3,int)
True
>>> isinstance(2/3,float)
False

 

Dette i motsetning til f.eks. Common Lisp hvor et heltall også er er rasjonalt tall, men selvsagt ikke motsatt.

CL-USER> (integerp 2/3)
NIL
CL-USER> (rationalp 2)
T
CL-USER> (rationalp 2/3)
T
CL-USER> (integerp 2)
T
CL-USER> (integerp 2/3)
NIL

[GeirGrusom]

Python is strongly typed as the interpreter keeps track of all variables types. ... Python tries to stay out of your way while giving you all you need to implement strong type checking.

What? Hvorfor skal en ville implementere sterk typesetting hvis språket allerede er sterkt typet?

Endret 24. september 2011 av GeirGrusom

[asicman]

Jeg trodde Python var sterkt typet? Virker ikke sånn.

Python sterk typet ja.

Uten og gå noe mer inn på det er det bra forklart Why is Python a dynamic language and also a strongly typed language

 

 

Her et utdrag fra linken du oppga:

 

 

The advantage to a strongly typed language is that you can trust what's going on: if you do something wrong, your program will generate a type error telling you where you went wrong, and you don't have to memorize a lot of arcane type-conversion rules or try to debug a situation where your variables have been silently changed without your knowledge.

 

Legg merke til min utheving og denne koden min fra 20:30 i går:

 

>>> x=3

>>> type(x)

<class 'int'>

>>> x/=2

>>> type(x)

<class 'float'>

 

Hvis man bruker denne definisjonen så kan man kanskje argumentere for at Python 2.7 er sterkt typet, men ikke Python 3.0. På en annen side kan man si at i Python 3 så ble / omgjort til en typekonverteringsfunksjon som kan konvertere heltall til float.

 

Jeg mener at Python er sterkt typet så jeg argumenterer ikke i mot det. Det er bare en kommentar til referansen din.

[torbjørn marø]

The advantage to a strongly typed language is that you can trust what's going on: if you do something wrong, your program will generate a type error telling you where you went wrong, and you don't have to memorize a lot of arcane type-conversion rules or try to debug a situation where your variables have been silently changed without your knowledge.

Ja dette var ikke en veldig presis formulering. Et språk er sterkt typet selv om en variabel/referanse kan holde/peke på ulike typer til ulike tidspunkt. Når du sier x/=2, så er jo det det samme som x = x / 2. Altså settes x til å peke på en ny verdi som er resultatet av x / 2. x / 2 kan igjen sees på som et funksjonskall (i mange språk er det det): div(x, 2). Denne funksjonen kan selvsagt returnere en annen type enn det parametrene sine er uten at man kan si at språket ikke er sterkt typet.

 

Endringen i Python dere snakker om her er interessant, og skaper debatt fordi den avviker fra C-tradisjonen. Men i Lisp-verden, som det allerede har blitt påpekt, er dette normen. 1 deltpå 3 i Common Lisp eller Clojure er 1/3, og ikke 0.

[torbjørn marø]

Python is strongly typed as the interpreter keeps track of all variables types. ... Python tries to stay out of your way while giving you all you need to implement strong type checking.

What? Hvorfor skal en ville implementere sterk typesetting hvis språket allerede er sterkt typet?

Sterk typing og sterk type-sjekking er jo selvsagt to ulike ting. Dynamisk typing impleserer at man i de fleste tilfeller ser bort fra typen (i funksjonskall f.eks). Verdiene er derimot i seg selv sterkt typet (i motsetning til i C f.eks., hvor det ikke er noe som skiller en int og en char annet enn hva du gjør med den.

 

Sterk typing skaper forvirring, og er noe man normalt ikke trenger å diskutere fordi de aller fleste språk har det. Dynamisk/statisk er en mye mere interessant diskusjon.

[sindreij]

Man må ikke glemme at python3 også har heltallsdivisjon:

 

>>> 3/2
1.5
>>> 3//2
1

 

Tenk på python3 sin / som en funksjon som tar inn to tall og gir ut en float. I motsetning til python2, som tar inn to tall og gir ut en float hvis en eller to av de er float, men ellers gir ut int. Jeg vil si python3 er mest logisk.

[Tok3n]

Har et lite problem som plager meg noe fryktelig.

 

Skal lese in noen verdier av denne formen X-Y.

 

Bruker da følgende kode : int x = tast.inInt( );. Det som er med denne koden er at jeg får feilmelding på grunn av "-". Noen som vet hvordan jeg kan få lest in to heltall med en bindestrek mellom ?

 

Vet at jeg kan gjøre det lett ved å først lese inn x deretter Y, men vil gjerne lære dette.

 

-Takk