Django 1.5 release notes

26 februari 2013

Välkommen till Django 1.5!

Dessa release notes täcker nya funktioner, samt några bakåtkompatibla ändringar som du bör vara medveten om när du uppgraderar från Django 1.4 eller äldre versioner. Vi har också tagit bort några funktioner, som beskrivs i vår utfasningsplan, och vi har börjat utfasningsprocessen för vissa funktioner.

Översikt

Den största nyheten i Django 1.5 är den konfigurerbara användarmodellen. Innan Django 1.5 var applikationer som ville använda Djangos auth-ramverk (django.contrib.auth) tvungna att använda Djangos definition av en ”användare”. I Django 1.5 kan du nu byta ut User-modellen mot en som du skriver själv. Detta kan vara en enkel förlängning av den befintliga User-modellen - till exempel kan du lägga till ett Twitter- eller Facebook-ID-fält - eller så kan du helt ersätta User med en helt anpassad för din webbplats.

Django 1.5 är också den första utgåvan med Python 3-stöd! Vi kallar detta stöd ”experimentellt” eftersom vi ännu inte anser att det är produktionsfärdigt, men allt är på plats för att du ska kunna börja porta dina appar till Python 3. Vår nästa release, Django 1.6, kommer att stödja Python 3 utan reservationer.

Andra anmärkningsvärda nya funktioner i Django 1.5 inkluderar:

• Stöd för att spara en delmängd av modellens fält - Model.save() accepterar nu ett update_fields-argument, så att du kan ange vilka fält som skrivs tillbaka till databasen när du anropar save(). Detta kan vara till hjälp vid operationer med hög samtidighet och kan förbättra prestandan.

• Bättre stöd för strömmande svar via den nya StreamingHttpResponse-svarsklassen.

• GeoDjango stöder nu PostGIS 2.0.

• … och mer; se nedan.

När det är möjligt försöker vi introducera nya funktioner på ett bakåtkompatibelt sätt enligt vår API-stabilitetspolicy. Men som med tidigare utgåvor levereras Django 1.5 med några mindre bakåtkompatibla ändringar; personer som uppgraderar från tidigare versioner av Django bör läsa listan noggrant.

En utfasad funktion som är värd att notera är övergången till ”ny stil” url tagg. Före Django 1.3 tolkades syntax som {% url myview %} felaktigt (Django ansåg att "myview" var ett bokstavligt namn på en vy, inte en mallvariabel med namnet myview). Django 1.3 och senare introducerade syntaxen {% load url from future %} för att införa det korrigerade beteendet där myview sågs som en variabel.

Slutsatsen av detta är att om du inte använder {% load url from future %} i dina mallar, måste du ändra taggar som {% url myview %} till {% url "myview" %}. Om du användte {% load url from future %} kan du helt enkelt ta bort den raden under Django 1.5

Kompatibilitet med Python

Django 1.5 kräver Python 2.6.5 eller högre, men vi rekommenderar starkt Python 2.7.3 eller högre. Stöd för Python 2.5 och lägre har tagits bort.

Denna förändring bör endast påverka ett litet antal Django-användare, eftersom de flesta leverantörer av operativsystem idag levererar Python 2.6 eller nyare som standardversion. Om du fortfarande använder Python 2.5 måste du dock hålla dig till Django 1.4 tills du kan uppgradera din Python-version. Enligt vår supportpolicy kommer Django 1.4 att fortsätta att få säkerhetsstöd fram till lanseringen av Django 1.6.

Django 1.5 körs inte på en Jython final release, eftersom Jythons senaste version för närvarande inte stöder Python 2.6. Jython erbjuder dock för närvarande en alfaversion med 2.7-stöd, och Django 1.5 stöder den alfaversionen.

Stöd för Python 3

Django 1.5 introducerar stöd för Python 3 - specifikt Python 3.2 och senare. Detta kommer i form av en enkel kodbas; du behöver inte installera en annan version av Django på Python 3. Detta innebär att du kan skriva applikationer som är inriktade på bara Python 2, bara Python 3 eller enstaka applikationer som stöder båda plattformarna.

Vi kallar dock detta stöd för ”experimentellt” för tillfället: även om det har fått omfattande tester via vår automatiserade testsvit, har det fått mycket lite testning i den verkliga världen. Vi har gjort vårt bästa för att eliminera buggar, men vi kan inte vara säkra på att vi har täckt alla möjliga användningar av Django.

Vissa funktioner i Django är inte tillgängliga eftersom de är beroende av programvara från tredje part som inte har portats till Python 3 ännu, inklusive:

• mySQL-databasens backend (beror på MySQLdb)

• ImageField (beror på PIL)

• LiveServerTestCase (beror på Selenium WebDriver)

Dessutom är Django mer än ett webbramverk; det är ett ekosystem av pluggbara komponenter. Vid denna tidpunkt har mycket få tredjepartsapplikationer portats till Python 3, så det är osannolikt att en verklig applikation kommer att ha alla sina beroenden uppfyllda under Python 3.

Därför rekommenderar vi att Django 1.5 inte används i produktion under Python 3. Använd istället detta tillfälle för att börja porta applikationer till Python 3. Om du är författare till en pluggbar komponent uppmuntrar vi dig att börja porta nu.

Vi planerar att erbjuda förstklassigt, produktionsfärdigt stöd för Python 3 i vår nästa version, Django 1.6.

Vad är nytt i Django 1.5

Konfigurerbar användarmodell

I Django 1.5 kan du nu använda din egen modell som lagringsplats för användarrelaterad data. Om ditt projekt behöver ett användarnamn med mer än 30 tecken, eller om du vill lagra användarnas namn i ett annat format än förnamn/ efternamn, eller om du vill lägga till anpassad profilinformation på ditt User-objekt, kan du nu göra det.

Om du har en återanvändbar applikation från tredje part som refererar till User-modellen kan du behöva göra vissa ändringar i hur du refererar till User-instanser. Du bör också dokumentera alla specifika funktioner i User-modellen som din applikation förlitar sig på.

Se dokumentation om anpassade användarmodeller för mer information.

Stöd för att spara en delmängd av modellens fält

Metoden Model.save() har fått ett nytt nyckelordsargument update_fields. Genom att använda detta argument är det möjligt att bara spara en utvald lista över modellens fält. Detta kan vara användbart av prestandaskäl eller när man försöker undvika att skriva över samtidiga ändringar.

Uppskjutna instanser (de som laddats med .only() eller .defer()) sparar automatiskt bara de laddade fälten. Om något fält ställs in manuellt efter laddning, kommer det fältet också att uppdateras vid sparandet.

Se Model.save() dokumentationen för mer information.

Cachelagring av relaterade modellinstanser

Vid traversering av relationer undviker ORM att hämta objekt som tidigare har laddats på nytt. Till exempel med handledningens modeller:

>>> first_poll = Poll.objects.all()[0]
>>> first_choice = first_poll.choice_set.all()[0]
>>> first_choice.poll is first_poll
True

I Django 1.5 utlöser den tredje raden inte längre en ny SQL-fråga för att hämta first_choice.poll; den ställdes in av den andra raden.

För en-till-en-relationer kan båda sidorna cachelagras. För många-till-en-relationer kan endast den enda sidan av relationen cachelagras. Detta är särskilt användbart i kombination med prefetch_related.

Explicit stöd för strömmande svar

Före Django 1.5 var det möjligt att skapa ett strömmande svar genom att skicka en iterator till HttpResponse. Men detta var opålitligt: alla mellanprogram som kom åt attributet content skulle förbruka iteratorn i förtid.

Du kan nu uttryckligen generera ett strömmande svar med den nya StreamingHttpResponse-klassen. Denna klass exponerar ett streaming_content-attribut som är en iterator.

Eftersom StreamingHttpResponse inte har något content-attribut, måste middleware som behöver tillgång till svarsinnehållet testa för strömmande svar och bete sig därefter.

{% verbatim %} mall tagg

För att göra det enklare att hantera JavaScript-mallar som kolliderar med Djangos syntax, kan du nu använda verbatim block-taggen för att undvika att analysera taggens innehåll.

Hämtning av ContentType-instanser associerade med proxymodeller

Metoderna ContentTypeManager.get_for_model() och ContentTypeManager.get_for_models() har ett nytt nyckelordsargument - respektive for_concrete_model och for_concrete_models. Genom att skicka False med detta argument är det nu möjligt att hämta ContentType som är associerad med proxymodeller.

Ny variabel view i klassbaserade vykontexter

I alla generiska klassbaserade vyer (eller alla klassbaserade vyer som ärver från ContextMixin) innehåller kontextordboken en view-variabel som pekar på View-instansen.

GeoDjango

• LineString och MultiLineString GEOS-objekt stöder nu metoderna interpolate() och project() (så kallad linjär referens).

• Egenskaperna wkb och hex för GEOSGeometry-objekt bevarar Z-dimensionen.

• Stöd för PostGIS 2.0 har lagts till och stöd för GDAL < 1.5 har tagits bort.

Nya handledningsprogram

Bland tilläggen till dokumentationen finns en omarbetad Tutorial 3 och en ny tutorial om testning. Ett nytt avsnitt, ”Advanced Tutorials”, erbjuder Hur man skriver återanvändbara appar samt en steg-för-steg-guide för nya bidragsgivare i Skriv din första patch för Django.

Mindre funktioner

Django 1.5 innehåller också flera mindre förbättringar som är värda att notera:

• Mallmotorn tolkar nu True, False och None som motsvarande Python-objekt.

• django.utils.timezone tillhandahåller ett hjälpmedel för att konvertera medvetna datatider mellan tidszoner. Se localtime().

• De generiska vyerna stöder OPTIONS-begäranden.

• Hanteringskommandon ger inte upphov till SystemExit längre när de anropas av kod från call_command(). Alla undantag som kommandot ger upphov till (oftast CommandError) sprids.

  Dessutom bör du nu använda self.stdout.write('message') och self.stderr.write('error') när du skriver ut fel eller meddelanden i dina anpassade kommandon (se anmärkningen om :ref:hanteringskommandon skriver ut <management-commands-output>).

• Hanteringskommandot dumpdata matar ut en rad i taget, vilket förhindrar minnesfel vid dumpning av stora dataset.

• I den lokala smaken för Kanada lades pq till de acceptabla koderna för Quebec. Det är en gammal förkortning.

• Dekoratorn receiver kan nu ansluta till mer än en signal genom att ange en lista med signaler.

• I administratören kan du nu filtrera användare efter grupper som de är medlemmar i.

• QuerySet.bulk_create() har nu ett batch_size-argument. Som standard är batch_size obegränsad utom för SQLite där en enda batch är begränsad så att 999 parametrar per fråga inte överskrids.

• Inställningarna LOGIN_URL och LOGIN_REDIRECT_URL accepterar nu även namn på vyfunktioner och named URL patterns. Detta gör att du kan minska antalet konfigurationsdubbleringar. Mer information finns i login_required()-dokumentationen.

• Django tillhandahåller nu en mod_wsgi auth hanterare.

• Metoderna QuerySet.delete() och Model.delete() kan nu använda snabbväg i vissa fall. Den snabba sökvägen möjliggör färre frågor och färre objekt som hämtas till minnet. Se QuerySet.delete() för mer information.

• En instans av ResolverMatch lagras på begäran som resolver_match.

• Som standard skickas alla loggmeddelanden som når loggern django när DEBUG är True till konsolen (om du inte omdefinierar loggern i din LOGGING-inställning).

• Vid användning av RequestContext är det nu möjligt att söka efter behörigheter genom att använda {% if 'someapp.someperm' in perms %} i mallar.

• Det är inte längre nödvändigt att ha mallarna 404.html och 500.html i rotkatalogen för mallar. Django kommer att mata ut några grundläggande felmeddelanden för båda situationerna när dessa mallar inte hittas. Det är fortfarande rekommenderat som god praxis att tillhandahålla dessa mallar för att presentera vackra felsidor för användaren.

• django.contrib.auth tillhandahåller en ny signal som skickas ut när en användare misslyckas med att logga in. Se user_login_failed

• Det nya alternativet loaddata --ignorenonexistent ignorerar data för fält som inte längre finns.

• assertXMLEqual() och assertXMLNotEqual() nya påståenden gör att du kan testa jämlikhet för XML-innehåll på en semantisk nivå, utan att bry dig om syntaxskillnader (mellanslag, attributordning etc.).

• RemoteUserMiddleware tvingar nu fram utloggning när REMOTE_USER-huvudet försvinner under samma webbläsarsession.

• Med cache-baserad sessionsbackend kan sessionsdata lagras i en cache som inte är standard.

• Index med flera kolumner kan nu skapas på modeller. Läs dokumentationen för index_together för mer information.

• Under Djangos loggningskonfiguration aktiveras verbose Deprecation-varningar och varningar fångas in i loggningssystemet. Loggade varningar dirigeras genom console loggningshanteraren, som som standard kräver att DEBUG är True för att utdata ska genereras. Resultatet är att DeprecationWarnings bör skrivas ut till konsolen i utvecklingsmiljöer på samma sätt som de har gjort i Python-versioner < 2.7.

• API:et för metoden django.contrib.admin.ModelAdmin.message_user() har ändrats för att acceptera ytterligare argument och lägga till funktioner som liknar django.contrib.messages.add_message(). Detta är användbart för att generera felmeddelanden från adminåtgärder.

• Administratörens listfilter kan nu anpassas per begäran tack vare den nya metoden django.contrib.admin.ModelAdmin.get_list_filter().

Bakåtkompatibla ändringar i 1.5

Varning

Utöver de ändringar som beskrivs i det här avsnittet bör du granska deprecation plan för alla funktioner som har tagits bort. Om du inte har uppdaterat din kod inom utfasningstiden för en viss funktion kan borttagningen av den framstå som en bakåtkompatibel ändring.

ALLOWED_HOSTS krävs i produktion

Den nya inställningen ALLOWED_HOSTS validerar begäran Host header och skyddar mot host-poisoning attacker. Den här inställningen krävs nu när DEBUG är False, annars kommer django.http.HttpRequest.get_host() att ge upphov till SuspiciousOperation. För mer information se full dokumentation för den nya inställningen.

Chefer på abstrakta modeller

Abstrakta modeller kan definiera en egen manager, och den managern :ref:` kommer att ärvas av alla konkreta modeller som utökar den abstrakta modellen <custom-managers-and-inheritance>`. Men om du försöker använda den abstrakta modellen för att anropa en metod på hanteraren, kommer ett undantag nu att uppstå. Tidigare skulle anropet ha tillåtits, men skulle ha misslyckats så snart som någon databasoperation försökte (vanligtvis med ett ”tabellen finns inte”-fel från databasen).

Om du har funktionalitet på en manager som du har anropat med hjälp av den abstrakta klassen, bör du migrera den logiken till en Python staticmethod eller classmethod på den abstrakta klassen.

Sammanhang i årsarkivets klassbaserade åsikter

För att vara konsekvent med de andra datumbaserade generiska vyerna, skickar YearArchiveView nu year i sammanhanget som ett datetime.date istället för en sträng. Om du använder {{ year }} i dina mallar måste du ersätta det med {{{ year|date:"Y" }}.

next_year och previous_year har också lagts till i sammanhanget. De beräknas i enlighet med allow_empty och allow_future.

Kontext i år och månad arkiv klassbaserade vyer

YearArchiveView och MonthArchiveView dokumenterades för att tillhandahålla en date_list sorterad i stigande ordning i sammanhanget, som deras funktionsbaserade föregångare, men det var faktiskt i fallande ordning. I 1.5 återställdes den dokumenterade ordningen. Du kanske vill lägga till (eller ta bort) nyckelordet reversed när du itererar på date_list i en mall:

{% for date in date_list reversed %}

ArchiveIndexView ger fortfarande en date_list i fallande ordning.

Kontext i TemplateView

För att vara konsekvent med utformningen av de andra generiska vyerna skickar TemplateView inte längre en params-ordbok till kontexten, utan istället variablerna från URLconf direkt till kontexten.

Icke-formulär data i HTTP-begäranden

request.POST kommer inte längre att inkludera data som postas via HTTP-förfrågningar med icke-formspecifika innehållstyper i rubriken. I tidigare versioner skulle data som postats med andra innehållstyper än multipart/form-data eller application/x-www-form-urlencoded fortfarande representeras i attributet request.POST. Utvecklare som vill komma åt de råa POST-data för dessa fall bör använda attributet request.body istället.

request_finished signal

Django brukade skicka signalen request_finished så snart som view-funktionen returnerade ett svar. Detta samverkade dåligt med :ref:streaming responses <httpresponse-streaming> som fördröjer generering av innehåll.

Denna signal skickas nu efter att innehållet är helt konsumerat av WSGI-gatewayen. Detta kan vara bakåtkompatibelt om du förlitar dig på att signalen avfyras innan du skickar svarsinnehållet till klienten. Om du gör det, bör du överväga att använda middleware istället.

Observera

Vissa WSGI-servrar och mellanprogram anropar inte alltid close på svarsobjektet efter att ha hanterat en begäran, särskilt uWSGI före 1.2.6 och Sentrys mellanprogram för felrapportering upp till 2.0.7. I dessa fall skickas inte signalen request_finished alls. Detta kan resultera i inaktiva anslutningar till databas- och memcache-servrar.

OPTIONS-, PUT- och DELETE-förfrågningar i testklienten

Till skillnad från GET och POST implementeras dessa HTTP-metoder inte av webbläsare. Istället används de i API:er som överför data i olika format som JSON eller XML. Eftersom sådana förfrågningar kan innehålla godtyckliga data försöker Django inte avkoda deras kropp.

Testklienten använde dock att bygga en frågesträng för OPTIONS och DELETE-förfrågningar som för GET, och en begärandekropp för PUT-förfrågningar som för POST. Denna kodning var godtycklig och inkonsekvent med Djangos beteende när den tar emot förfrågningarna, så den togs bort i Django 1.5.

Om du använde parametern data i en OPTIONS- eller DELETE-begäran måste du konvertera den till en frågesträng och lägga till den i parametern path.

Om du använde parametern data i en PUT-begäran utan content_type måste du koda dina data innan du skickar dem till testklienten och ange argumentet content_type.

Systemversionen av simplejson används inte längre

Som förklaras nedan, Django 1.5 avskaffar django.utils.simplejson till förmån för Python 2.6:s inbyggda json-modul. I teorin är denna förändring harmlös. Tyvärr, på grund av inkompatibilitet mellan versioner av simplejson, kan det utlösa fel under vissa omständigheter.

JSON-relaterade funktioner i Django 1.4 använde alltid django.utils.simplejson. Denna modul var faktiskt:

• En systemversion av simplejson, om en sådan fanns tillgänglig (dvs. import simplejson fungerar), om den var nyare än Djangos inbyggda kopia eller om den hade C-hastigheterna, eller

• Modulen json från standardbiblioteket, om den var tillgänglig (dvs. Python 2.6 eller senare), eller

• En inbyggd kopia av version 2.0.7 av simplejson.

I Django 1.5 använder dessa funktioner Pythons modul json, som är baserad på version 2.0.9 av simplejson.

Det finns inga kända inkompatibiliteter mellan Djangos kopia av version 2.0.7 och Pythons kopia av version 2.0.9. Det finns dock vissa inkompatibiliteter mellan andra versioner av simplejson:

• Medan API:et simplejson är dokumenterat som att det alltid returnerar Unicode-strängar, kan den valfria C-implementationen returnera en bytestring. Detta åtgärdades i Python 2.7.

• simplejson.JSONEncoder fick ett namedtuple_as_object nyckelordsargument i version 2.2.

Mer information om dessa inkompatibiliteter finns i ticket #18023.

Nettoresultatet är att om du har installerat simplejson och din kod använder Djangos serialiseringsinterna direkt - till exempel django.core.serializers.json.DjangoJSONEncoder, kan bytet från simplejson till json` bryta din kod. (I allmänhet dokumenteras inte ändringar av interna funktioner; vi gör ett undantag här)

Vid denna tidpunkt anser underhållarna av Django att användning av json från standardbiblioteket ger den starkaste garantin för bakåtkompatibilitet. De rekommenderar att man använder det från och med nu.

Strängtyper av parametrar för hashermetoder

Om du har skrivit en custom password hasher, bör dina metoder encode(), verify() eller safe_summary() acceptera Unicode-parametrar (password, salt eller encoded). Om någon av hashing-metoderna behöver bytestrings kan du använda force_bytes() för att koda strängarna.

Validering av previous_page_number och next_page_number

Vid användning av :doc:object pagination </topics/pagination>`, kontrollerade inte metoderna ``previous_page_number() och next_page_number() i objektet Page om det returnerade numret låg inom det befintliga sidintervallet. Nu kontrolleras det och ett InvalidPage-undantag uppstår när antalet är antingen för lågt eller för högt.

Beteendet för autocommit-databasalternativet på PostgreSQL ändrades

PostgreSQL: s autocommit-alternativ fungerade inte som tidigare annonserat. Det fungerade för enstaka transaktionsblock, men efter att det första blocket hade lämnats återställdes aldrig autocommit-beteendet. Denna bugg är nu fixad i 1.5. Även om detta bara är en buggfix, är det värt att kontrollera dina applikationsbeteenden om du använder PostgreSQL tillsammans med autocommit-alternativet.

Sessionen sparades inte på 500 svar

Djangos session middleware kommer att hoppa över att spara sessionsdata om svarets statuskod är 500.

E-postkontroll vid misslyckad admininloggning

Före Django 1.5, om du försökte logga in i administratörsgränssnittet och av misstag använde din e-postadress istället för ditt användarnamn, skulle administratörsgränssnittet ge en varning som meddelade att din e-postadress inte var ditt användarnamn. I Django 1.5 har införandet av custom user models krävt att denna varning tas bort. Detta ändrar inte inloggningsbeteendet på administratörssidan; det påverkar bara varningsmeddelandet som visas under ett visst inloggningsfel.

Förändringar i testernas utförande

Vissa ändringar har införts i utförandet av tester som kan vara bakåtkompatibla för vissa testuppställningar:

Databasspolning i django.test.TransactionTestCase

Tidigare trunkerades testdatabasen före varje testkörning i en TransactionTestCase.

För att kunna köra enhetstester i vilken ordning som helst och för att se till att de alltid är isolerade från varandra kommer TransactionTestCase nu att återställa databasen efter varje testkörning istället.

Ingen mer återställning av implicita DB-sekvenser

TransactionTestCase tester som används för att återställa primärnyckelsekvenser automatiskt tillsammans med databasspolningsåtgärderna som beskrivs ovan.

Detta har ändrats så att inga sekvenser implicit återställs. Detta kan orsaka att TransactionTestCase-tester som är beroende av hårdkodade primärnyckelvärden inte fungerar.

Det nya attributet reset_sequences kan användas för att tvinga fram det gamla beteendet för TransactionTestCase som kan behöva det.

Beställning av tester

För att säkerställa att all TestCase-kod startar med en ren databas, körs testerna nu i följande ordning:

• Först körs alla enhetstester (inklusive unittest.TestCase, SimpleTestCase, TestCase och TransactionTestCase) utan att någon särskild ordning garanteras eller upprätthålls mellan dem.

• Därefter körs alla andra tester (t.ex. doctests) som kan ändra databasen utan att återställa den till dess ursprungliga tillstånd.

Detta bör inte orsaka några problem såvida du inte har befintliga doctests som antar att ett TransactionTestCase som körts tidigare lämnade något databastillstånd bakom sig eller enhetstester som förlitar sig på att någon form av tillstånd bevaras efter utförandet av andra tester. Sådana tester är redan mycket ömtåliga och måste nu ändras för att kunna köras oberoende.

cleaned_data ordbok sparas för ogiltiga formulär

Ordboken cleaned_data är nu alltid närvarande efter validering av formuläret. När formuläret inte valideras innehåller det bara de fält som klarade valideringen. Du bör testa om valideringen lyckades med metoden is_valid() och inte med närvaron eller frånvaron av attributet cleaned_data på formuläret.

Beteendet hos syncdb med flera databaser

syncdb frågar nu databasroutrarna för att avgöra om innehållstyper (när contenttypes` är aktiverat) och behörigheter (när auth` är aktiverat) ska skapas i måldatabasen. Tidigare skapades de i standarddatabasen, även när en annan databas angavs med alternativet --database.

Om du använder syncdb på flera databaser bör du se till att dina routrar tillåter synkronisering av innehållstyper och behörigheter till endast en av dem. Se dokumenten om beteende för Contrib-appar med flera databaser för mer information.

XML-deserializer analyserar inte dokument med en DTD

För att förhindra exponering för överbelastningsattacker relaterade till externa entitetsreferenser och entitetsexpansion, vägrar XML-modellens deserializer nu att analysera XML-dokument som innehåller en DTD (DOCTYPE-definition). Eftersom XML-serialisatorn inte matar ut en DTD kommer detta inte att påverka den typiska användningen, utan endast de fall där specialtillverkade XML-dokument skickas till Djangos modelldeserialisator.

Formulärets standard max_num

Ett (standard)värde på None för argumentet max_num i en formulärfabrik tillåter inte längre som standard ett valfritt antal formulär i formuläret. Istället, för att förhindra minnesutmattningsattacker, är standardvärdet nu en gräns på 1000 formulär. Denna gräns kan höjas genom att uttryckligen ange ett högre värde för max_num.

Diverse

• django.forms.ModelMultipleChoiceField returnerar nu en tom QuerySet som det tomma värdet istället för en tom lista.

• int_to_base36() ger korrekt upphov till ett TypeError istället för ValueError för icke-integrala indata.

• Mallfiltret slugify är nu tillgängligt som en standard Python-funktion på django.utils.text.slugify`(). På samma sätt finns remove_tags tillgängligt på django.utils.html.remove_tags().

• Uppladdade filer skapas inte längre som körbara som standard. Om du vill att de ska vara körbara ändrar du FILE_UPLOAD_PERMISSIONS efter dina behov. Det nya standardvärdet är 0o666 (oktal) och det aktuella umask-värdet maskeras först.

• F expressions stödde bitvisa operatorer med & och |. Dessa operatorer är nu tillgängliga med hjälp av .bitand() och .bitor() istället. Borttagandet av & och | gjordes för att vara konsekvent med Q()-uttryck och QuerySet som kombinerar där operatorerna används som booleska AND- och OR-operatorer.

• I ett filter()-anrop, när F uttryck innehöll uppslagningar som spänner över flervärdiga relationer, återanvände de inte alltid samma relationer som andra uppslagningar längs samma kedja. Detta ändrades, och nu kommer F()-uttryck alltid att använda samma relationer som andra uppslagningar inom samma filter()-anrop.

• Malltaggen csrf_token är inte längre innesluten i en div. Om du behöver HTML-validering mot DTD:er före HTML5 Strict bör du lägga till en div runt den på dina sidor.

• Malltaggbiblioteket adminmedia, som endast innehöll den föråldrade malltaggen {% admin_media_prefix %}, har tagits bort. Försök att ladda den med {% load adminmedia %} kommer att misslyckas. Om dina mallar fortfarande innehåller den här raden måste du ta bort den.

• På grund av en implementeringsförseelse var det möjligt att använda django.contrib.redirects utan att aktivera django.contrib.sites. Detta är inte tillåtet längre. Om du använder django.contrib.redirects, se till att INSTALLED_APPS innehåller django.contrib.sites.

• BoundField.label_tag <django.forms.BoundField.label_tag>`() escapar nu sitt argument contents. För att undvika HTML-escaping, använd django.utils.safestring.mark_safe() på argumentet innan du skickar det.

• Åtkomst till omvända en-till-en-relationer hämtade via select_related() ger nu upphov till DoesNotExist istället för att returnera None.

Funktioner som inte längre är aktuella i 1.5

django.contrib.localflavor

Appen localflavor contrib har delats upp i separata paket. django.contrib.localflavor i sig kommer att tas bort i Django 1.6, efter en accelererad avskrivning.

De nya paketen finns tillgängliga på GitHub. Kärnteamet kan inte effektivt underhålla dessa paket på lång sikt - det omfattar bara ett dussin länder för närvarande; i likhet med översättningar kommer underhållet att överlämnas till intresserade medlemmar i samhället.

django.contrib.markup

Markup Contrib-modulen har utgått och kommer att följa ett påskyndat utrangeringsschema. Direkt användning av Python markup-bibliotek eller taggbibliotek från tredje part föredras framför att Django behåller denna funktionalitet i ramverket.

AUTH_PROFILE_MODULE

I och med införandet av custom user models finns det inte längre något behov av en inbyggd mekanism för att lagra användarprofildata.

Du kan fortfarande definiera användarprofilmodeller som har en en-till-en-relation med User-modellen - i själva verket kommer detta att vara ett lämpligt designmönster att följa för många applikationer som behöver associera data med ett användarkonto. Inställningen AUTH_PROFILE_MODULE och metoden django.contrib.auth.models.User.get_profile() för åtkomst till användarprofilmodellen bör dock inte användas längre.

Streamingbeteende för :klass:`~django.http.HttpResponse`

Django 1.5 avskaffar möjligheten att strömma ett svar genom att skicka en iterator till HttpResponse. Om du förlitar dig på detta beteende, byt till StreamingHttpResponse. Se :ref:explicit-streaming-responses ovan.

I Django 1.7 och senare kommer iteratorn att konsumeras omedelbart av HttpResponse.

django.utils.simplejson

Eftersom Django 1.5 tappar stödet för Python 2.5 kan vi nu förlita oss på att modulen json finns tillgänglig i Pythons standardbibliotek, så vi har tagit bort vår egen kopia av simplejson. Du bör nu importera json istället för django.utils.simplejson.

Tyvärr kan denna ändring ha oönskade sidoeffekter, på grund av inkompatibilitet mellan olika versioner av simplejson – se :ref:bakåtkompatibla ändringar <simplejson-incompatibilities> sektionen. Om du förlitar dig på funktioner som lagts till i simplejson efter att det blev Pythons json, bör du importera simplejson explicit.

django.utils.encoding.StrAndUnicode

Mix-in django.utils.encoding.StrAndUnicode har blivit föråldrad. Definiera en __str__ metod och använd django.utils.encoding.python_2_unicode_compatible dekoratorn istället.

django.utils.itercompat.product

Funktionen django.utils.itercompat.product har blivit föråldrad. Använd den inbyggda itertools.product() istället.

kommando för hantering av cleanup

Hanteringskommandot cleanup har utgått och ersatts av clearsessions.

skriptet daily_cleanup.py

Det odokumenterade skriptet daily_cleanup.py har utgått. Använd istället kommandot clearsessions.

nyckelordsargumentet depth i select_related

Nyckelordsargumentet depth i select_related() har blivit föråldrat. Du bör använda fältnamn istället.