Vad är nytt i Python 3.0

Författare:

Guido van Rossum

I den här artikeln förklaras de nya funktionerna i Python 3.0 jämfört med 2.6. Python 3.0, även känd som ”Python 3000” eller ”Py3K”, är den första någonsin avsiktligt bakåtkompatibla Python-versionen. Python 3.0 släpptes den 3 december 2008. Det finns fler ändringar än i en vanlig version, och fler som är viktiga för alla Python-användare. Ändå, efter att ha smält förändringarna, kommer du att upptäcka att Python verkligen inte har förändrats så mycket - i stort sett fixar vi mest välkända irritationer och vårtor och tar bort en hel del gammal cruft.

Den här artikeln försöker inte ge en fullständig specifikation av alla nya funktioner, utan försöker i stället ge en praktisk översikt. För fullständig information hänvisas till dokumentationen för Python 3.0 och/eller de många PEP:er som refereras till i texten. Om du vill förstå den fullständiga implementeringen och designrationaliteten för en viss funktion, har PEPs vanligtvis mer detaljer än den vanliga dokumentationen; men observera att PEPs vanligtvis inte hålls uppdaterade när en funktion har implementerats fullt ut.

På grund av tidsbrist är detta dokument inte så komplett som det borde ha varit. Som alltid när det gäller en ny version innehåller filen Misc/NEWS i källdistributionen en mängd detaljerad information om varje liten sak som har ändrats.

Vanliga stötestenar

I det här avsnittet listas de få ändringar som troligen kommer att göra dig förvirrad om du är van vid Python 2.5.

Vyer och iteratorer istället för listor

Vissa välkända API:er returnerar inte längre listor:

  • dict-metoderna dict.keys(), dict.items() och dict.values() returnerar ”views” istället för listor. Till exempel fungerar inte detta längre: k = d.keys(); k.sort(). Använd k = sorted(d) istället (detta fungerar även i Python 2.5 och är lika effektivt).

  • Dessutom stöds inte längre metoderna dict.iterkeys(), dict.iteritems() och dict.itervalues().

  • map() och filter() returnerar iteratorer. Om du verkligen behöver en lista och indatasekvenserna alla är lika långa, är en snabb lösning att linda in map() i list(), t.ex. list(map(...)), men en bättre lösning är ofta att använda en listförståelse (speciellt när den ursprungliga koden använder lambda), eller att skriva om koden så att den inte behöver en lista alls. Särskilt knepigt är map() som används för funktionens bieffekter; den korrekta transformationen är att använda en vanlig for-loop (eftersom det bara skulle vara slöseri att skapa en lista).

    Om indatasekvenserna inte är lika långa kommer map() att stanna vid slutet av den kortaste av sekvenserna. För full kompatibilitet med map() från Python 2.x, linda även in sekvenserna i itertools.zip_longest(), t.ex. map(func, *sequences) blir list(map(func, itertools.zip_longest(*sequences))).

  • range() beter sig nu som xrange() brukade bete sig, förutom att den fungerar med värden av godtycklig storlek. Den senare finns inte längre.

  • zip() returnerar nu en iterator.

Beställning av jämförelser

Python 3.0 har förenklat reglerna för att beställa jämförelser:

  • Jämförelseoperatorerna för ordningsföljd (<, <=, >=, >) ger upphov till ett TypeError-undantag när operanderna inte har en meningsfull naturlig ordningsföljd. Således är uttryck som 1 < '', 0 > None eller len <= len inte längre giltiga, och t.ex. None < None ger upphov till TypeError istället för att returnera False. En följd av detta är att det inte längre är meningsfullt att sortera en heterogen lista – alla element måste vara jämförbara med varandra. Observera att detta inte gäller för operatorerna == och !=: objekt av olika ojämförbara typer jämförs alltid ojämlikt med varandra.

  • sorted() och list.sort() accepterar inte längre cmp-argumentet som ger en jämförelsefunktion. Använd key-argumentet istället. OBS: Argumenten key och reverse är nu ”endast nyckelord”.

  • Funktionen cmp() bör betraktas som borta, och specialmetoden __cmp__() stöds inte längre. Använd __lt__() för sortering, __eq__() med __hash__() och andra jämförelser efter behov. (Om du verkligen behöver cmp()-funktionaliteten kan du använda uttrycket (a > b) - (a < b) som motsvarighet till cmp(a, b))

Heltal

  • PEP 237: I huvudsak har long bytt namn till int. Det vill säga, det finns bara en inbyggd integraltyp, som heter int; men den beter sig mestadels som den gamla long-typen.

  • PEP 238: Ett uttryck som 1/2 returnerar en float. Använd 1//2 för att få det trunkerande beteendet. (Den senare syntaxen har funnits i flera år, åtminstone sedan Python 2.2.)

  • Konstanten sys.maxint togs bort, eftersom det inte längre finns någon gräns för värdet på heltal. Däremot kan sys.maxsize användas som ett heltal som är större än alla praktiska index för listor eller strängar. Det överensstämmer med implementationens ”naturliga” heltalsstorlek och är vanligtvis detsamma som sys.maxint i tidigare utgåvor på samma plattform (med samma byggalternativ).

  • repr() av ett långt heltal inkluderar inte längre det efterföljande L, så kod som ovillkorligen tar bort det tecknet kommer att hugga bort den sista siffran istället. (Använd str() istället.)

  • Octal-literaler är inte längre av formen 0720; använd 0o720 istället.

Text vs. Data istället för Unicode vs. 8-bitars

Allt du trodde att du visste om binärdata och Unicode har förändrats.

  • Python 3.0 använder begreppen text och (binär) data istället för Unicode-strängar och 8-bitarssträngar. All text är Unicode, men kodad Unicode representeras som binär data. Den typ som används för att hålla text är str, den typ som används för att hålla data är bytes. Den största skillnaden med 2.x-situationen är att alla försök att blanda text och data i Python 3.0 ger upphov till TypeError, medan om du skulle blanda Unicode och 8-bitars strängar i Python 2.x, skulle det fungera om 8-bitars strängen råkade innehålla endast 7-bitars (ASCII) byte, men du skulle få UnicodeDecodeError om den innehöll icke-ASCII-värden. Detta värdespecifika beteende har orsakat många ledsna miner genom åren.

  • Som en konsekvens av denna filosofiska förändring måste i stort sett all kod som använder Unicode, kodningar eller binära data sannolikt ändras. Förändringen är till det bättre, eftersom det i 2.x-världen fanns många buggar som hade att göra med att blanda kodad och okodad text. För att vara förberedd i Python 2.x, börja med att använda unicode för all okodad text och str endast för binär eller kodad data. Då kommer verktyget 2to3 att göra det mesta av arbetet åt dig.

  • Du kan inte längre använda u"..."-litteraler för Unicode-text. Du måste dock använda b"..."-litteraler för binära data.

  • Eftersom typerna str och bytes inte kan blandas måste du alltid uttryckligen konvertera mellan dem. Använd str.encode() för att gå från str till bytes, och bytes.decode() för att gå från bytes till str. Du kan också använda bytes(s, encoding=...) respektive str(b, encoding=...).

  • Precis som str är typen bytes oföränderlig. Det finns en separat föränderlig typ för att hålla buffrade binära data, bytearray. Nästan alla API:er som accepterar bytes accepterar också bytearray. Det mutabla API:et är baserat på collections.MutableSequence.

  • Alla backslashes i råa stränglitteraler tolkas bokstavligt. Detta innebär att '\U' och '\u' escapes i råa strängar inte behandlas speciellt. Till exempel är r'\u20ac' en sträng med 6 tecken i Python 3.0, medan i 2.6 var ur'\u20ac' det enda ”euro”-tecknet. (Naturligtvis påverkar denna förändring endast råa stränglitteraler; eurotecknet är '\u20ac' i Python 3.0.)

  • Den inbyggda abstrakta typen basestring togs bort. Använd str istället. Typerna str och bytes har inte tillräckligt många gemensamma funktioner för att motivera en gemensam basklass. Verktyget 2to3 (se nedan) ersätter varje förekomst av basestring med str.

  • Filer som öppnas som textfiler (fortfarande standardläget för open()) använder alltid en kodning för att mappa mellan strängar (i minnet) och byte (på disken). Binära filer (öppnade med ett b i lägesargumentet) använder alltid byte i minnet. Det innebär att om en fil öppnas med fel läge eller kodning kommer I/O sannolikt att misslyckas, istället för att i tysthet producera felaktiga data. Det innebär också att även Unix-användare måste ange rätt läge (text eller binärt) när de öppnar en fil. Det finns en plattformsberoende standardkodning som på Unix-plattformar kan ställas in med miljövariabeln LANG (och ibland även med några andra plattformsspecifika lokalrelaterade miljövariabler). I många fall, men inte alla, är systemets standard UTF-8; du bör aldrig räkna med denna standard. Alla program som läser eller skriver mer än ren ASCII-text bör förmodligen ha ett sätt att åsidosätta kodningen. Det finns inte längre något behov av att använda de kodningsmedvetna strömmarna i modulen codecs.

  • De initiala värdena för sys.stdin, sys.stdout och sys.stderr är nu textfiler med endast en kod (dvs. de är instanser av io.TextIOBase). För att läsa och skriva bytesdata med dessa strömmar måste du använda deras io.TextIOBase.buffer-attribut.

  • Filnamn skickas till och returneras från API:er som (Unicode)-strängar. Detta kan medföra plattformsspecifika problem eftersom filnamn på vissa plattformar är godtyckliga byte-strängar. (Som en lösning accepterar de flesta API:er (t.ex. open() och många funktioner i modulen os) som tar emot filnamn bytes-objekt såväl som strängar, och några API:er har ett sätt att be om ett bytes-returvärde. Således returnerar os.listdir() en lista över bytes-instanser om argumentet är en bytes-instans, och os.getcwdb() returnerar den aktuella arbetskatalogen som en bytes-instans. Observera att när os.listdir() returnerar en lista med strängar, utelämnas filnamn som inte kan avkodas korrekt i stället för att ge upphov till UnicodeError.

  • Vissa system-API:er som os.environ och sys.argv kan också ge problem när de byte som görs tillgängliga av systemet inte kan tolkas med hjälp av standardkodningen. Att ställa in variabeln LANG och köra programmet på nytt är förmodligen det bästa tillvägagångssättet.

  • PEP 3138: repr() av en sträng escapar inte längre icke-ASCII-tecken. Den escapar dock fortfarande kontrolltecken och kodpunkter med icke-utskrivbar status i Unicode-standarden.

  • PEP 3120: Standardkodningen för källan är nu UTF-8.

  • PEP 3131: Icke-ASCII-bokstäver är nu tillåtna i identifierare. (Standardbiblioteket är dock fortfarande ASCII-only, med undantag för namn på bidragsgivare i kommentarer)

  • Modulerna StringIO och cStringIO är borta. Istället importerar du modulen io och använder io.StringIO eller io.BytesIO för text respektive data.

  • Se även Unicode HOWTO, som uppdaterades för Python 3.0.

Översikt över syntaxändringar

Detta avsnitt ger en kort översikt över varje syntaktisk förändring i Python 3.0.

Ny syntax

  • PEP 3107: Annoteringar för funktionens argument och returvärde. Detta ger ett standardiserat sätt att kommentera en funktions parametrar och returvärde. Det finns ingen semantik kopplad till sådana annoteringar förutom att de kan introspekteras vid körning med hjälp av attributet __annotations__. Avsikten är att uppmuntra experimenterande genom metaklasser, dekoratorer eller ramverk.

  • PEP 3102: Endast nyckelordsargument. Namngivna parametrar som förekommer efter *args i parameterlistan måste anges med nyckelordssyntax i anropet. Du kan också använda en naken * i parameterlistan för att ange att du inte accepterar en argumentlista med variabel längd, men att du har argument som endast innehåller nyckelord.

  • Nyckelord som argument tillåts efter listan över basklasser i en klassdefinition. Detta används av den nya konventionen för att specificera en metaklass (se nästa avsnitt), men kan användas för andra ändamål också, så länge metaklassen stöder det.

  • PEP 3104: nonlocal uttalande. Med nonlocal x kan du nu tilldela direkt till en variabel i ett yttre (men icke-globalt) scope. nonlocal är ett nytt reserverat ord.

  • PEP 3132: Utökad uppackning av Iterable. Du kan nu skriva saker som a, b, *rest = some_sequence. Och till och med *rest, a = stuff. Objektet rest är alltid en (eventuellt tom) lista; den högra sidan kan vara vilken iterabel som helst. Exempel:

    (a, *rest, b) = intervall(5)
    

    Detta sätter a till 0, b till 4 och rest till [1, 2, 3].

  • Ordboksförståelse: {k: v for k, v in stuff} betyder samma sak som dict(stuff) men är mer flexibelt. (Detta är PEP 274 bekräftat. :-)

  • Mängdlitteraler, t.ex. {1, 2}. Observera att {} är en tom ordlista; använd set() för en tom uppsättning. Uppsättningsförståelse stöds också; t.ex. betyder {x for x in stuff} samma sak som set(stuff) men är mer flexibelt.

  • Nya oktala literaler, t.ex. 0o720 (redan i 2.6). De gamla oktalliteralerna (0720) är borta.

  • Nya binära literaler, t.ex. 0b1010 (redan i 2.6), och det finns en ny motsvarande inbyggd funktion, bin().

  • Byteslitteraler introduceras med en ledande b eller B, och det finns en ny motsvarande inbyggd funktion, bytes().

Ändrad syntax

  • PEP 3109 och PEP 3134: Ny raise-syntax för satser: raise [expr [från expr]]. Se nedan.

  • as och with är nu reserverade ord. (Sedan 2.6, faktiskt.)

  • True, False och None är reserverade ord. (2.6 tillämpade delvis restriktionerna för None redan)

  • Ändra från except exc, var till except exc as var. Se PEP 3110.

  • PEP 3115: Ny syntax för metaklasser. Istället för:

    klass C:
        __metaklass__ = M
        ...
    

    måste du nu använda:

    klass C(metaklass=M):
        ...
    

    Den modulglobala variabeln __metaclass__ stöds inte längre. (Den var en krycka för att göra det lättare att använda nya klasser som standard utan att härleda alla klasser från object)

  • Listförståelser stöder inte längre den syntaktiska formen [... för var i item1, item2, ...]. Använd [... for var in (item1, item2, ...)] i stället. Observera också att listcomprehensions har en annan semantik: de är närmare syntaktiskt socker för ett generatoruttryck inuti en list()-konstruktor, och i synnerhet läcker inte längre loopkontrollvariablerna ut i det omgivande omfånget.

  • ellips (...) kan användas som ett atomiskt uttryck var som helst. (Tidigare var det bara tillåtet i slices.) Dessutom måste det nu stavas som .... (Tidigare kunde det också stavas som . ., av en ren olyckshändelse i grammatiken)

Borttagen syntax

  • PEP 3113: Uppackning av tuple-parametrar borttagen. Du kan inte längre skriva def foo(a, (b, c)): .... Använd def foo(a, b_c): b, c = b_c istället.

  • Tog bort bakvända apostrofer (använd repr() istället).

  • Borttagen <> (använd != istället).

  • Borttaget nyckelord: exec() är inte längre ett nyckelord; det finns kvar som en funktion. (Lyckligtvis accepterades funktionssyntaxen även i 2.x.) Observera också att exec() inte längre tar ett stream-argument; istället för exec(f) kan du använda exec(f.read()).

  • Heltalslitteraler stöder inte längre en efterföljande l eller L.

  • Stränglitteraler stöder inte längre en ledande u eller U.

  • Syntaxen from module import * är endast tillåten på modulnivå, inte längre inuti funktioner.

  • Den enda acceptabla syntaxen för relativ import är from .[module] import name. Alla import-former som inte börjar med . tolkas som absolut import. (PEP 328)

  • Klassiska klasser är borta.

Ändringar som redan finns i Python 2.6

Eftersom många användare förmodligen hoppar direkt från Python 2.5 till Python 3.0, påminner det här avsnittet läsaren om nya funktioner som ursprungligen utformades för Python 3.0, men som portades tillbaka till Python 2.6. Motsvarande avsnitt i Vad är nytt i Python 2.6 bör konsulteras för längre beskrivningar.

Förändringar i biblioteket

På grund av tidsbegränsningar täcker detta dokument inte uttömmande de mycket omfattande ändringarna av standardbiblioteket. PEP 3108 är referensen för de större ändringarna av biblioteket. Här är en kortfattad genomgång:

  • Många gamla moduler togs bort. Vissa, som gopherlib (används inte längre) och md5 (ersatt av hashlib), var redan utfasade av PEP 4. Andra togs bort som ett resultat av att stödet för olika plattformar som Irix, BeOS och Mac OS 9 togs bort (se PEP 11). Vissa moduler valdes också ut för borttagning i Python 3.0 på grund av brist på användning eller för att en bättre ersättning finns. Se PEP 3108 för en uttömmande lista.

  • Paketet bsddb3 togs bort eftersom dess närvaro i det centrala standardbiblioteket med tiden har visat sig vara en särskild börda för de centrala utvecklarna på grund av instabila tester och Berkeley DB:s utgivningsschema. Paketet lever dock vidare och underhålls externt på https://www.jcea.es/programacion/pybsddb.htm.

  • Vissa moduler döptes om eftersom deras gamla namn inte lydde PEP 8, eller av olika andra skäl. Här är listan:

    Gammalt namn

    Nytt namn

    _winreg

    winreg

    KonfigParser

    configparser

    kopiera_reg

    copyreg

    Köa

    SocketServer

    socketserver

    markupbas

    _markupbase

    repr

    reprlib

    test.test_support

    test.support

  • Ett vanligt mönster i Python 2.x är att ha en version av en modul implementerad i ren Python, med en valfri accelererad version implementerad som ett C-tillägg; till exempel pickle och cPickle. Detta innebär att varje användare av dessa moduler måste importera den snabbare versionen och återgå till den rena Python-versionen. I Python 3.0 betraktas de accelererade versionerna som implementeringsdetaljer av de rena Python-versionerna. Användare bör alltid importera standardversionen, som försöker importera den accelererade versionen och faller tillbaka på den rena Python-versionen. Paret pickle / cPickle fick denna behandling. Modulen profile finns med på listan för 3.1. Modulen StringIO har gjorts om till en klass i modulen io.

  • Vissa relaterade moduler har grupperats i paket, och vanligtvis har namnen på undermodulerna förenklats. De resulterande nya paketen är:

    • dbm (anydbm, dbhash, dbm, dumbdbm, gdbm, whichdb).

    • html (HTMLParser, htmlentitydefs).

    • http (httplib, BaseHTTPServer, CGIHTTPServer, SimpleHTTPServer, Cookie, cookielib).

    • tkinter (alla Tkinter-relaterade moduler utom turtle). Målgruppen för turtle bryr sig egentligen inte om tkinter. Observera också att från och med Python 2.6 har funktionaliteten i turtle förbättrats avsevärt.

    • urllib (urllib, urllib2, urlparse, robotparse).

    • xmlrpc (xmlrpclib, DocXMLRPCServer, SimpleXMLRPCServer).

Några andra ändringar i standardbiblioteksmoduler, som inte täcks av PEP 3108:

  • Dödade sets. Använd den inbyggda set()-klassen.

  • Rensning av modulen sys: tog bort sys.exitfunc(), sys.exc_clear(), sys.exc_type, sys.exc_value, sys.exc_traceback. (Observera att sys.last_type etc. kvarstår)

  • Uppstädning av typen array.array: metoderna read() och write() är borta; använd fromfile() och tofile() istället. Dessutom är typkoden 'c' för array borta – använd antingen 'b' för bytes eller 'u' för Unicode-tecken.

  • Uppstädning av modulen operator: tog bort sequenceIncludes() och isCallable().

  • Uppstädning av modulen thread: acquire_lock() och release_lock() är borta; använd acquire() och release() istället.

  • Rensning av modulen random: tog bort API:et jumpahead().

  • Modulen new är borta.

  • Funktionerna os.tmpnam(), os.tempnam() och os.tmpfile() har tagits bort till förmån för modulen tempfile.

  • Modulen tokenize har ändrats för att fungera med bytes. Den huvudsakliga ingångspunkten är nu tokenize.tokenize(), istället för generate_tokens.

  • string.letters och dess vänner (string.lowercase och string.uppercase) är borta. Använd string.ascii_letters etc. istället. (Anledningen till borttagandet är att string.letters och dess vänner hade ett lokalspecifikt beteende, vilket är en dålig idé för globala ”konstanter” med så attraktiva namn)

  • Döpte om modulen __builtin__ till builtins (tar bort understrecken och lägger till ett ’s’). Variabeln __builtins__ som finns i de flesta globala namnrymder är oförändrad. För att modifiera en builtin bör du använda builtins, inte __builtins__!

PEP 3101: En ny metod för strängformatering

  • Ett nytt system för inbyggda strängformateringsoperationer ersätter strängformateringsoperatorn %. (Operatorn % stöds dock fortfarande; den kommer att avskrivas i Python 3.1 och tas bort från språket vid en senare tidpunkt) Läs PEP 3101 för hela scoopet.

Ändringar av undantag

API:erna för att skapa och fånga upp undantag har rensats upp och nya kraftfulla funktioner har lagts till:

  • PEP 352: Alla undantag måste härledas (direkt eller indirekt) från BaseException. Detta är roten i undantagshierarkin. Detta är inte nytt som en rekommendation, men kravet att ärva från BaseException är nytt. (Python 2.6 tillät fortfarande att klassiska klasser togs upp, och lade ingen begränsning på vad du kan fånga) Som en följd av detta är strängundantag äntligen helt och hållet döda.

  • Nästan alla undantag bör egentligen härledas från Exception; BaseException bör endast användas som basklass för undantag som endast bör hanteras på högsta nivå, t.ex. SystemExit eller KeyboardInterrupt. Det rekommenderade idiomet för att hantera alla undantag utom denna senare kategori är att använda except Exception.

  • StandardError togs bort.

  • Undantag beter sig inte längre som sekvenser. Använd istället attributet args.

  • PEP 3109: Upphävande av undantag. Du måste nu använda raise Exception(args) istället för raise Exception, args. Dessutom kan du inte längre uttryckligen ange en traceback; om du måste göra detta kan du istället tilldela direkt till attributet __traceback__ (se nedan).

  • PEP 3110: Fånga upp undantag. Du måste nu använda except SomeException as variable istället för except SomeException, variable. Dessutom raderas variabeln explicit när except-blocket lämnas.

  • PEP 3134: Kedjning av undantag. Det finns två fall: implicit kedjning och explicit kedjning. Implicit kedjning sker när ett undantag tas upp i ett except eller finally hanterarblock. Detta sker vanligtvis på grund av en bugg i hanterarblocket; vi kallar detta för ett sekundärt undantag. I det här fallet sparas det ursprungliga undantaget (som hanterades) som attributet __context__ för det sekundära undantaget. Explicit kedjning görs med denna syntax:

    raise SecondaryException() från primary_exception
    

    (där primary_exception är vilket uttryck som helst som producerar ett undantagsobjekt, förmodligen ett undantag som tidigare fångats upp). I det här fallet lagras det primära undantaget i attributet __cause__ för det sekundära undantaget. Den spårning som skrivs ut när ett ohanterat undantag inträffar går genom kedjan av attributen __cause__ och __context__ och skriver ut en separat spårning för varje komponent i kedjan, med det primära undantaget högst upp. (Java-användare kanske känner igen det här beteendet)

  • PEP 3134: Exception-objekt lagrar nu sin traceback som attributet __traceback__. Detta innebär att ett undantagsobjekt nu innehåller all information om ett undantag och att det finns färre anledningar att använda sys.exc_info() (även om den senare inte har tagits bort).

  • Några undantagsmeddelanden har förbättrats när Windows misslyckas med att ladda en tilläggsmodul. Till exempel är felkod 193 nu %1 är inte en giltig Win32-applikation. Strängar hanterar nu icke-engelska lokala språk.

Övrigt Övriga förändringar

Operatorer och specialmetoder

  • != returnerar nu motsatsen till ==, såvida inte == returnerar NotImplemented.

  • Begreppet ”obundna metoder” har tagits bort från språket. När man refererar till en metod som ett klassattribut får man nu ett vanligt funktionsobjekt.

  • __getslice__(), __setslice__() och __delslice__() dödades. Syntaxen a[i:j] översätts nu till a.__getitem__(slice(i, j)) (eller __setitem__() eller __delitem__(), när den används som ett tilldelnings- respektive raderingsmål).

  • PEP 3114: standardmetoden next() har bytt namn till __next__().

  • Specialmetoderna __oct__() och __hex__() har tagits bort – oct() och hex() använder nu __index__() för att konvertera argumentet till ett heltal.

  • Borttaget stöd för __members__ och __methods__.

  • Funktionsattributen med namnet func_X har bytt namn till __X__, vilket frigör dessa namn i namnrymden för funktionsattribut för användardefinierade attribut. Således har func_closure, func_code, func_defaults, func_dict, func_doc, func_globals, func_name bytt namn till __closure__, __code__, __defaults__, __dict__, __doc__, __globals__, __name__, respektive.

  • __nonzero__() är nu __bool__().

Inbyggnader

  • PEP 3135: Ny super(). Du kan nu anropa super() utan argument och (förutsatt att detta är i en vanlig instansmetod definierad i en class-sats) rätt klass och instans kommer automatiskt att väljas. Med argument är beteendet hos super() oförändrat.

  • PEP 3111: raw_input() har bytt namn till input(). Det innebär att den nya funktionen input() läser en rad från sys.stdin och returnerar den med den efterföljande nya raden borttagen. Den ger upphov till EOFError om inmatningen avslutas i förtid. För att få det gamla beteendet hos input(), använd eval(input()).

  • En ny inbyggd funktion next() lades till för att anropa metoden __next__() på ett objekt.

  • Avrundningsstrategin och returtypen för funktionen round() har ändrats. Exakta halvvägsfall avrundas nu till närmaste jämna resultat istället för bort från noll. (Till exempel returnerar round(2,5) nu 2 i stället för 3.) round(x[, n]) delegerar nu till x.__round__([n]) istället för att alltid returnera en float. Den returnerar i allmänhet ett heltal när den anropas med ett enda argument och ett värde av samma typ som x när den anropas med två argument.

  • Flyttat intern() till sys.intern().

  • Borttaget: apply(). Istället för apply(f, args) använd f(*args).

  • Tog bort callable(). Istället för callable(f) kan du använda isinstance(f, collections.Callable). Funktionen operator.isCallable() är också borta.

  • Tog bort coerce(). Denna funktion fyller inte längre något syfte nu när klassiska klasser har försvunnit.

  • Tog bort execfile(). Istället för execfile(fn) använd exec(open(fn).read()).

  • Tog bort file-typen. Använd open(). Det finns nu flera olika typer av strömmar som open kan returnera i modulen io.

  • Tog bort reduce(). Använd functools.reduce() om du verkligen behöver det, men 99 procent av tiden är en explicit for-loop mer läsbar.

  • Tog bort reload(). Använd imp.reload().

  • Borttagen. dict.has_key() – använd operatorn in istället.

Ändringar i Build och C API

På grund av tidsbrist följer här en mycket ofullständig lista över ändringar i C API.

  • Stöd för flera plattformar togs bort, inklusive men inte begränsat till Mac OS 9, BeOS, RISCOS, Irix och Tru64.

  • PEP 3118: Nytt buffert-API.

  • PEP 3121: Initialisering och slutförande av tilläggsmodul.

  • PEP 3123: Anpassning av PyObject_HEAD till standard C.

  • Inget mer C API-stöd för begränsad exekvering.

  • c API:erna PyNumber_Coerce(), PyNumber_CoerceEx(), PyMember_Get() och PyMember_Set() tas bort.

  • Nytt C API PyImport_ImportModuleNoBlock(), fungerar som PyImport_ImportModule() men blockerar inte importlåset (returnerar ett fel istället).

  • Byt namn på C-nivå slot och metod för boolesk konvertering: nb_nonzero är nu nb_bool.

  • Tog bort METH_OLDARGS och WITH_CYCLE_GC från C API.

Prestanda

Nettoresultatet av 3.0-generaliseringarna är att Python 3.0 kör pystone-riktmärket cirka 10% slägre än Python 2.5. Den största orsaken är troligen borttagandet av special-casing för små heltal. Det finns utrymme för förbättringar, men det kommer att ske efter att 3.0 har släppts!

Portning till Python 3.0

För portning av befintlig Python 2.5 eller 2.6 källkod till Python 3.0 är den bästa strategin följande:

  1. (Förkunskapskrav:) Börja med utmärkt testtäckning.

  2. Porta till Python 2.6. Detta bör inte vara mer arbete än den genomsnittliga porten från Python 2.x till Python 2.(x+1). Se till att alla dina tester godkänns.

  3. (Använder fortfarande 2.6:) Slå på kommandoradsväxeln -3. Detta aktiverar varningar om funktioner som kommer att tas bort (eller ändras) i 3.0. Kör din testsvit igen och fixa kod som du får varningar om tills det inte finns några varningar kvar och alla dina tester fortfarande är godkända.

  4. Kör 2to3 käll-till-källa-översättaren över ditt källkodsträd. Kör resultatet av översättningen under Python 3.0. Fixa manuellt upp eventuella kvarvarande problem, fixa problem tills alla tester godkänns igen.

Det är inte rekommenderat att försöka skriva källkod som körs oförändrad under både Python 2.6 och 3.0; du skulle behöva använda en mycket förvrängd kodningsstil, t.ex. undvika print-satser, metaklasser och mycket mer. Om du underhåller ett bibliotek som behöver stödja både Python 2.6 och Python 3.0, är det bästa tillvägagångssättet att ändra steg 3 ovan genom att redigera 2.6-versionen av källkoden och köra 2to3-översättaren igen, snarare än att redigera 3.0-versionen av källkoden.

För portning av C-tillägg till Python 3.0, se Portning av tilläggsmoduler till Python 3.