Färdig med Codecademy, vad är nästa steg för att lära sig mer Python?

Nästa steg är att du lär dig databaser och sedan skriver simpla python program som läser/skriver data från databasen. Du kommer behöva databaser för de flesta program/webbsidor så lika bra att lära sig det direkt.

T.ex.

Gör ett python program som ansluter till din databas. Programmet ska kolla om tabellerna "produkter" och "kunder" finns. Om inte, skapa dem. Sedan kollar programmet att kolumnerna product_id, product_name, product_description och product_price finns i tabellen produkter. Om inte, skapa dem. Programmet ska sedan kolla om kolumnerna kund_id och kund_namn finns. Om inte, skapa dem.

Fortsätt sedan med t.ex. att programmet ska kunna visa alla produkter, lägga till nya produkter, uppdatera existerande produkter samt ta bort produkter. Likadant med kunder.

Har du fått det klart lägger du till en ny tabell som heter "ordrar" och lägger till kolumnerna order_id, product_id och kund_id och du ska kunna skapa en ny order i programmet. Efter det har du ett ordersystem klart.

Du kommer lära dig otroligt mycket på att göra ett eget, simpelt ordersystem till skillnad från att grotta ner dig i någon bok.

Ja, analogt så när jag började använda Matlab så skrev jag jobbiga C-liknande `for`-loopar över index och annat, innan polletten trillade ner gällande vektoroperationer. På samma sätt så skrev jag C-likt i Python, innan jag tidigt upptäckte `for … in …`-syntaxen, och senare hur det kunde samspela med generatorer när man skrev egna klasser och andra tricks. Efter ytterligare ett tag så upptäckte jag hur `map()`/`reduce()`/`filter()`, och sedan (ofta än bättre) list comprehensions (och liknande för dictionaries, sets, …) kan lösa extremt mycket utan att behöva skriva speciellt många loopar alls, om man strukturerar sina funktioner och datatyper på ett bra sätt.

Sådant är typiskt saker som är svåra att få riktigt grepp om när man läser om koncepten i guider och annat, precis på samma sätt som det tog ett tag innan jag förstod Matlabs tillvägagångssätt, men när man sitter och strider med programskrivande så kommer det någon gång plinga till i huvudet: "aha, här återuppfinner jag ju egentligen bara det där hjulet jag läste om någon gång", och så rullar det på.

När man sedan upptäckt dessa delar så är det säkert en period då man överanvänder koncepten, innan man med än mer övning upptäcker en bättre balans, så att man använder alla delar av språket på de sätt de är tänkta.

Python nämns ofta som ett bra språk att starta med för att syntaxen är enkel, men det finns i mina ögon fler anledningar:

• Språkets design premierar hela tiden att skriva läsbar och enkel kod framför att skriva "smarta lösningar" som ingen (inklusive en själv om en vecka) kan få grepp om framöver. Att lära sig skriva "enkelt" så att alla logiska steg är tydligt synliga är bra för inlärning.

• Man blir belönad av att lära sig tänka på skillnaderna mellan de olika datastrukturer som erbjuds och när de ska användas, samtidigt som de inte är bedövande många. Att lära sig tänka i termer om datastrukturer är något som ärrade dataloger brukar tala om med drömska blickar.

• Jag fick aldrig något riktigt grepp om objektorientering när jag introducerades till det genom Java, då fördelarna lätt doldes i laviner av syntax för enklare uppgifter. Jag hade sedan ytterligare en utflykt i detta med relativt färska PHP 5, men det var rätt hemskt. Det var inte förrän jag senare började skriva Python som allt plötsligt blev så mycket tydligare och fördelarna kom fram i ljuset, vilket jag sedan kunde ta med mig tillbaka till Java, C++, PHP, etc.

Skriver man `import this` i en Pythontolk så får man visdomsord av Tim Peters (får man en välanvänd sorteringsalgoritm uppkallad efter sig så räknas man som insatt ) som är roliga att läsa under tiden man lär sig mer, då de växer ju mer man förstår om språket.

För mig personligen så har de flesta ordentliga svallvågor av inlärning kommit när jag skrivit program som har haft någon faktiskt applikation. Det är med sådant som jag verkligen har kunnat fastna framför datorn i frenetiska sessioner, samtidigt som man glömmer bort att sova och äta och sådant världsligt .

Stack Overflow har en tråd i en liknande anda som denna: Python progression path — From apprentice to guru. En annan lärorik sak man kan göra är att ordna Stack Overflows Pythontaggade frågor efter röstantal och börja läsa. Vissa saker är säkerligen helt ointressanta till en början ("metaklasser" är exempelvis något som de allra flesta aldrig kommer stöta på), men man kan säkert hitta någon intressant fråga som man lär sig något av och framöver komma tillbaka till de trådar som är oförståeliga för tillfället när man behöver dem.

Vad menar du med Matlabs begränsningar. Matlab är ju rätt fritt och du använder det som ett programmeringsspråk och inte ett scriptspråk som de flesta verkar göra.

Anyhow, hitta på lite roliga saker att göra, det mesta går ju att göra i alla språk. Kanske är det ett textbaserat spel? Någon rolig konvertera funktion till graf eller liknande? Handlar ju bara om att hitta på något som verkar intressant.

Att blanda in multicoreprocessorer och annat är att titta på det ur ett prestandaperspektiv. Det är inte därför jag använder OOP (där det passar), utan det används där det helt enkelt förenklar kodningsprocessen; snarare som ett arkitekturverktyg.

Jag hade skrivit småsaker i Python i flera år innan jag ens skrev `class` för första gången, så det är definitivt inte något som är fastbultat i fundamentet på samma sätt som i exempelvis Java, men samtidigt så känns det som en extremt naturlig del av språket om man väljer att inkorporera det.

Jämförelser mellan Ruby och Python hamnar oftast i personliga preferenser, inte minst beroende på inom vilket område man behöver använda språket. Författaren till Ruby har sagt att han skapade Ruby 1993 med tanken om att göra en "mer objektorienterad variant av Python", men Python har utvecklats en hel del sedan 1993. Vissa av de argument som syns i liknande diskussioner är i mina ögon ganska ytliga, som att man definierar längden av ett Rubyobjekt som en fundamental egenskap, medans man i Python definierar en `__len__`-metod för klassen och sedan använder ett funktionsanrop på objektet. I praktiken blir detta snarare bara en syntaxegenskap hos språket än en fundamental skillnad (inget hindrar en från att definiera en `length`-egenskap i Python som gör samma sak, men då skriver man egentligen inte "Python"). Python skippar ju dock (mer eller mindre, går emulera som `properties` om man verkligen vill, eller undgå problemet genom att följa "frivilliga" namngivningskonventioner) hela biten med inkapsling, vilket många ser som en grundbult i OOP, så det är inte en helt traditionell applikation av konceptet.

Jag har inte skrivit en rad Ruby själv utan bara sett andras kod, så ovanstående synpunkter bör inte tolkas alltför tungt. Vilka begränsningar man hittar inom Python beror också på vad man gör för något. Jag har skrivit små skriptliknande projekt för kraftigt skiftade saker, enklare webbtjänster och en saker för att analysera fysikalisk mätdata. Just inom det senare området så är Python numera något av ett standardspråk som används tills prestandabegränsningar börjar bli påminda, då man kan migrera dessa bitar till andra språk (oftare och oftare C++, men även Fortran är vanligt).

För ett nuvarande projekt så har jag en C++-bas som kör tyngre beräkningar på stora mätdatamängder och presenterar resultatet i en utgallrad och färdigkalibrerad datastruktur, varpå Pythonskript sedan tar hand om att plotta dataserier via kopplingar till ett underliggande C++-bibliotek. Tanken är att C++-biten blir av "write once"-karaktär som kan stå och tugga TB med mätdata i timmar/dagar för att spotta ut någon GB med intressanta data till disk, och att den mesta manuella programmeringstiden tillbringas med att skapa kortare Pythonskript som kan ta datastrukturen från C++ och exempelvis grafiskt presentera och exportera olika dataserier.

Kollar jag i Pythonkoden för projektet (för närvarande ~1500 rader) så har jag bara skrivit en klass på ~70 rader (för att läsa in en viss inställningsfil för en detektor och presentera några beräkningar av dess värden), och ingen alls på ~500 rader C++, men båda delar jobbar mot större existerande C++-kodbaser som presenterar egentligen allt via klasser. Vem som helst som argumenterar för att OOP (eller någon annan paradigm) är en "silver bullet" skulle jag personligen tycka är vilse. På samma sätt är Dijkstras (påstådda) och Armstrongs lösryckta citat på egna ben rätt bananas om de försöker förkasta hela OOP-världen, men det är troligen inte så trubbigt de är tänkta att tolkas. I praktiska problem så verkar det inte vara några problem att låta olika paradigmer samexistera och sköta det de gör bäst — och då är det ju praktiskt att Python låter användaren välja .

Personligen skriver jag i Vim med ett fåtal fräsiga plugins (Syntastic kan få ett hedersomnämnande; har även (svagt) överlapp med instruktionerna i [1]) och startar gärna detta i en Tmux-session så att jag kan ha (minst! ) en tillhörande terminal ständigt tillgänglig i ett splittat fönster för att sköta testkörningar, filhantering, versionshantering, etc. När man är klar för stunden så kan man sedan bara detacha sessionen, och öppna den igen när man kommer tillbaka, eller för den delen attacha från en annan dator och fortsätta. Ibland har jag riggat så att terminalen automatiskt kör programmet varje gång jag sparar filen i Vim, vilket kan vara smidigt, men det passar inte alltid.

Att få igång Tmux och terminaler på Windows är nog mer jobb än det är värt, så där är det nog bättre att sikta på någon "färdig" lösning. PyCharm är rätt poppis, men en lite större best. PyScripter är nog mer avskalad. Att satsa på Vim/Emacs/annan kompetent allmän texteditor gör ju dock att man lär sig mer generella färdigheter som man kan ha nytta av även i andra sammanhang.

Mer "uttrycksfulla" språk som Java, där det lätt blir mycket "boilerplate"-kod närapå kräver en större IDE för allt bortom skoluppgifter (minns att jag använde Jgrasp för den Javakurs jag läst, utan att använda speciellt många funktioner utöver den integrerade "kompilera och kör"-panelen), men i Pythonvärlden är det många [citation needed] som känner att en rätt avskalad upplevelse räcker väldigt långt, och i sig kommer med fördelar. What IDE to use for Python? — Stack Overflow till "räddning" igen, med en sorts popularitetsomröstning, där Vim "leder". Jag har i ärlighetens namn inte använt något annat än Vim för att skriva Python, så jag är nog inte rätt person att uttala mig om alternativen.

[1]: Turning Vim into a modern Python IDE

Cut-and-paste integration med Windows-clipboard finns som standardfunktion, förutsatt att man kör win32 versionen av Emacs och inte den i CygWin. Googla på "clipboard-kill-region/clipboard-kill-ring-save/clipboard-yank", använd "C-h b" för att se vilken tangent dessa funktioner är bundna till. Går att binda dem till C-x/C-c/C-v för att få "Windows beteende", (ctrl x, ctrl c och ctrl v) men är man van med Emacs är det rätt irriterande att ändra ctrl-c till att vara copy-to-clipboard...

Har inte testat guiderna på annat än OSX och Linux, kör i.o.f.s. Windows på hemdatorn idag men programmerandet sker via en Linux-installation körandes på VirtualBox. Ska titta lite på dessa, då Emacs extensioner typiskt är skrivna i elisp så ska de fungera oavsett plattform.

Annars har jag hört mycket gott om Sublime Text, är kanske enklare att komma igång med om man inte använt Emacs tidigare.

Man behöver inte ens blanda in prestanda i det hela, inte heller multicore för att OOP ska vara en dålig idé. Så fort du använder dig av "concurrent programming" eller på något sätt har flera trådar i ditt program så är OOP en rätt stor bössa riktad mot fötterna då "metoder" typiskt modifiera något inkapslat tillstånd och att göra dessa tillståndsförändringar på rätt sätt med flera trådar är dömt att misslyckas.

OOP kräver att du definierar typhierarkier, A is-a B. Problemet att det bara fungerar på tillrättalagda leksaksexempel, det man vill ha är polymorfism men det kräver absolut inte OOP. I Python kan man använda duck-typing för polymorfism så finns ingen anledning att stoppa in en stel klasshierarki, vad ger det mer än att addera boilerplate?

PyCon 2003