Come imparare Python senza studiare.

Come imparare Python senza studiare?, chiedevano scherzosamente qualche giorno fa su Forumpython.it. Era una battuta, si capisce. Se non fosse... a un livello più profondo, molti principianti sembrano farsi questa domanda sul serio. Se non fosse... a un livello ancora più profondo, potrebbe aver senso davvero, domandarsi come imparare Python senza studiare. Quindi provo a rispondere come se fosse una domanda seria.

Si può guidare anche senza patente.

Mettiamola così: è la maledizione che Steve Jobs ha lanciato sul mondo nel 1984 (coincidenze...) e non possiamo più farci nulla.
Capiamoci: la tendenza a presentare cose difficili come se fossero semplici per esigenze commerciali non è certo nata con Steve Jobs e il suo Macintosh. Ma nel nostro piccolo mondo dell'informatica, quello è stato lo spartiacque: il computer nelle case di tutti, il computer accessibile a tutti. Anche e soprattutto cognitivamente, accessibile a tutti. E con la progressiva, capillare diffusione dei sistemi informatici, oggi sembra inevitabile che tutti possano sapere come si usa un computer. Non è scontato che dovesse andare così: anche l'aspirapolvere è molto diffuso e il marketing prova a convincerci che è facile da usare. "Non dovete neppure cambiare il sacchetto!", eppure in genere diamo almeno un'occhiata al libretto di istruzioni per capire come si puliscono le parti interne. Ma il computer, quello è diverso: da quella volta nel 1984, pretendiamo di sapere già come si usa. Deve essere intuitivo, innato addirittura. Nessuno Stato permette ai suoi cittadini di guidare una macchina senza aver preso la patente: ma affidiamo ogni cosa, dalla comunicazione politica al conto in banca, a un oggetto estremamente complesso che, per effetto di un marketing concepito in un'epoca lontana, tutti ormai concordiamo essere intuitivo da usare.

Inevitabilmente questo trend ha investito il mondo della programmazione. Oggi molti nuovi arrivati si chiedono con stupore perché, dal momento che il computer deve essere intuitivo da usare, non può essere anche intuitivo da programmare. Ma attenzione, neanche questa è una cosa nuova. Chi scrive ha accumulato anni di storie dell'orrore a guardare come Excel viene usato da persone normali che non hanno il minimo sospetto dei concetti che manovrano. Tu fai una lista di persone da invitare alla festa, quindi evidenzi in giallo quelli che non sei sicuro se verranno: che problema c'è? Ma "viene/non viene" è un dato, logica di business; "giallo" è formattazione, logica di presentazione. Se vuoi aggiungere un dato, devi usare una colonna a parte e metterci una "x" per chi non viene, una "o" per chi viene e un "?" quando non sei sicuro.
Un foglio di calcolo semplifica la vita lasciandoci mescolare allegramente dati, formattazione, operazioni sui dati. E perché questo dovrebbe essere sbagliato, se è veloce e funziona?

Impara a programmare in 10 secondi.

Tanti anni fa programmare un computer era sinonimo di usare un computer, nel senso che quei computer erano usati solo da chi li programmava. Ogni generazione di programmatori ha avuto il suo mito dei Bei Tempi Andati quando programmare era una cosa seria. Ancora oggi l'archetipo del real programmer è quello stabilito in due testi di culto, entrambi del 1983 (un anno prima del Macintosh... coincidenze): Real Programmers Don't Use Pascal e The Story of Mel. La cosa interessante è che sono entrambi testi satirici: perché già all'epoca la noiosa supponenza della vecchia guardia nei confronti dei "giovani d'oggi" meritava la presa in giro.

Oggi, inevitabilmente, i computer diventano "una cosa da programmare" per un numero sempre crescente di persone, che però sono l'esatto opposto del real programmer. Sono ricercatori di biologia che vogliono un modo di indagare i dati di laboratorio. Genitori che montano il loro sistema di domotica. Analisti finanziari. Sociologi interessati a fare sentiment analysis. Impallinati dei big data. Hobbysti: ma non hobbysti del computer come i nerd di Linux negli anni '90. Hobbysti di qualsiasi altra cosa, che oggi usano e programmano il computer, ma non necessariamente per amore del computer e della programmazione.
Queste sono persone che, se Pandas ci mette più di cinque righe di codice sullo Jupyter Notebook per trasformare i loro dati in un bel grafico, perdono la pazienza. Sono persone che "stanno studiando Python" e non hanno ancora capito precisamente come funziona un ciclo "for", ma già si chiedono perché è così difficile fare scraping delle statistiche del sito del fantacalcio. Più in generale, sono persone assediate da WhatsApp, distratte da Facebook... vogliono risultati e li vogliono adesso.

Di nuovo, sia chiaro: questo è sempre successo. Ma è impressionante vedere come e in che quantità e con quale intensità succede oggi, rispetto a vent'anni fa. A questo proposito, la pietra di paragone resta questo articolo di Peter Norvig, dal titolo molto celebre "Impara da solo a programmare in 10 anni". Riporta la data del 2001, ma la Wayback Machine lo registra fin dall'inizio del 1998. A rileggerlo oggi, da un lato resta valido nel suo principio generale. Dall'altro, fa tenerezza vedere come è invecchiato.
Allora come oggi, orde di nuovi arrivati correvano a comprare improbabili libri del tipo "Impara Java in 24 ore" nell'illusione che programmare fosse difficile e impegnativo per tutti gli altri: per quelli che non sanno il trucco, per quelli che non hanno comprato e letto il libro magico.

A costoro, Norvig spiega pazientemente che non si diventa bravi a niente, in meno di dieci anni. Suonare uno strumento, dipingere, giocare a tennis, fotografare. Programmare un computer. Sono attività che richiedono dieci anni di apprendistato. Norvig ha ragione, naturalmente. 

Quello che oggi fa tenerezza, però, è che lui implicitamente assume che queste persone vogliano imparare a essere programmatori, in quelle famose 24 ore. Lo assume perché all'epoca in effetti era così: programmatori e utenti erano ancora, per lo più, comunità separate. I suggerimenti di Norvig sono molto sensati, ma...: "Parla con i programmatori, e leggi i loro programmi; lavora sui progetti di altri programmatori; impara almeno mezza dozzina di linguaggi diversi; capisci quanto tempo impiega un computer a eseguire un'istruzione, a prelevare un dato dalla memoria; fatti coinvolgere in un progetto di standardizzazione (...)". 

...Ma vi immaginate, oggi, rispondere così a quello che vuole fare scraping del sito del fantacalcio? E badate, non voglio fare ironia. Il fatto è che, rispetto a 20 anni fa, oggi la maggior parte di chi vuole programmare non vuole anche necessariamente fare il programmatore.
Tuttavia, nel merito, le osservazioni di Peter Norvig continuano ad avere lo stesso valore di venti anni fa. Dopo tutto, i computer sono sempre le stesse macchine di Turing. E allora che cosa è cambiato nel frattempo, tanto da accostare una platea così vasta ed eterogenea di persone a un mondo che, in essenza, è rimasto esotico e inaccessibile come ai tempi della storia di Mel?

La lunga corsa per tornare bambini.

Beh, in parte non c'è bisogno che vi dica che cosa è cambiato, per i programmatori come per tutti. Tuttavia i capisaldi dell'architettura del software e delle pratiche di programmazione che seguiamo oggi, erano già lì venti o trenta anni fa: i database relazionali (dal 1974), la concorrenza (1965), le architetture client/server (dagli anni '60), la programmazione a oggetti (1962), le metodologie formalizzate di sviluppo (anni '60-'90) fino all'Agile Manifesto (2001)... La Bibbia dei pattern è del 1994; la Bibbia degli algoritmi è degli anni '70.
Non voglio dire che il mestiere del programmatore non sia cambiato nel tempo. Ma ecco il punto: da un lato, l'uso del computer e le modalità di utilizzo sono progredite molto in fretta verso una grande semplicità apparente che ne ha favorito la diffusione. Dall'altro, le tecniche di programmazione dei computer non sono progredite neanche lontanamente alla stessa velocità in questa direzione.

I linguaggi sono certamente diventati più "semplici": Mel il real programmer si rifiutava di usare il compilatore, perché lui sapeva ottimizzare meglio del compilatore. Ma, sorpresa!, proprio per questo motivo il linguggio C (1973) e il compilatore hanno finito per vincere la partita: il talento dei programmatori come Mel poteva essere speso meglio che a fare elegantissime ottimizzazioni, visto che comunque la crescente velocità dei processori compensava per questi piccoli difetti. Adesso sembra incredibile, ma C era il linguaggio "facile" in quel contesto. E poi, naturalmente, sono nati molti altri linguaggi di alto livello capaci di manipolare astrazioni più complesse, e tra questi anche Python (1991).

E intanto sono nati anche gli "ambienti di programmazione": software che integrano un linguaggio vero e proprio con un programma che dovrebbe rendere più agevole lo sviluppo delle applicazioni. Quando nel 1990 Alan Cooper vendette a Bill Gates il suo prototipo rivoluzionario di gui-builder, allora chiamato Tripod, Microsoft pensò di integrarlo con il linguaggio Basic. Il risultato fu spettacolare: potevi costruire il design di una finestra in modo intuitivo, visuale. Le azioni più comuni dietro a ciascun elemento erano già codificate; il resto, potevi scrivertelo da solo con il Basic. A dire il vero il linguaggio non era granché. Ma la parte visuale partorita dal genio di Cooper era rivoluzionaria, e alla fine VisualBasic contribuì in maniera determinante a portare in casa Microsoft quella enorme platea di consumatori che Steve Ballmer tanto desiderava: developers, developers, developers!
VisualBasic, Delphi (1995) e i loro nipotini hanno contribuito a sfocare la differenza tradizionale tra utenti e programmatori, e tra programmatori professionali e hobbysti. O forse, meglio ancora, a creare la categoria dei programmatori hobbysti, ben distinta dalla cultura hacker degli anni '60 e '70 documentata nel Jargon File. Qui la differenza è spiegata bene: un hacker è "una persona che ama esplorare i dettagli dei sistemi programmabili e spingere all'estremo le loro possibilità, dove invece la maggior parte degli utenti preferisce imparare il minimo necessario".

Questa tendenza a spostare il focus della programmazione sul risultato da raggiungere rapidamente ha fatto molta strada. Da un lato perché i "sistemi programmabili" sono diventati onnipresenti e indispensabili, ma anche talmente complessi che c'è sempre meno tempo per "esplorare i dettagli". Dall'altro perché in ogni caso questo approccio ha avvicinato alla programmazione un numero sterminato di persone, ben oltre le possibilità della cultura selettiva della prima comunità hacker. Infine perché l'industria oggi ha sempre più bisogno di realizzare prodotti complessi in tempi brevi, con processi chiari e condivisi da molti sviluppatori: nessuno oggi può permettersi di perdere le giornate ad analizzare il geniale ma labirintico codice di Mel il real programmer.

Così, trent'anni dopo VisualBasic, oggi è tutta una proliferazione di drag'n'drop, dashboard, workflows, toolbox, template e plugins. La tipologia di elementi e interazioni che negli anni '90 avremmo usato per descrivere un gioco strategico o gestionale, oggi descrive bene un linguaggio di programmazione (e certi linguaggi di programmazione hanno un sito da videogioco anni '90). Per tutto questo, naturalmente!, esiste un acronimo: si chiamano LCDP (Low Code Development Platform) e NCDP (No Code etc. etc.), ma se volete fare i disinvolti potete dire tutto insieme LCNC (Low Code / No Code).
Ma anche questa non è propriamente una novità. Ambienti di programmazione e linguaggi visuali erano in circolazione già vent'anni fa, a partire naturalmente dal progenitore di tutti quanti: HyperCard (1987). E poi c'erano Squeak (1996), Scratch (2002) e molti altri. La cosa interessante era che spesso si trattava di piattaforme didattiche, con lo scopo di insegnare ai bambini a programmare in modo interattivo e visualmente stimolante.
In trent'anni, i programmatori sono diventati utenti e poi sono tornati bambini.

E Python in tutto questo?

A proposito di didattica dell'informatica: alcuni anni fa la BBC ha lanciato Micro:bit, un vasto programma basato su una scheda hardware dedicata da distribuire nelle scuole. Tra i linguaggi supportati da Micro:bit c'è Scratch, che va ancora alla grande. Ma c'è anche Python, naturalmente!
Il che ci porta al nostro linguaggio preferito.

I moderni ambienti LCNC in gran parte espandono la tradizione dei linguaggi non-procedurali di quarta generazione, e sono per lo più domain-specific o comunque orientati a determinati tipi di business application. Python, d'altra parte, è un linguaggio general purpose della generazione precedente ed è paragonabile più che altro a Java o C# (sebbene con la flessibilità di un linguaggio di scripting).

Di Python è sempre stata lodata la semplicità d'uso; e d'altra parte la sua comunità ha sempre alimentato un forte interesse per l'uso di Python nella didattica e una benevola apertura verso i principianti. Tuttavia, attenzione: la semplicità di Python non è da misurare con il metro dell'utente, ma pur sempre con quello del programmatore. È una semplicità che scaturisce da una eleganza intrinseca, da alcune astrazioni intelligenti (pensate a quante cose sono iterabili e quanto si può fare con un semplice "for"), da una forte espressività e da tutto ciò che è distillato nel suo Zen. La semplicità di Python si capisce meglio per contrasto con linguaggi come Perl, non per analogia con ambienti come Delphi.
È una semplicità che richiede pur sempre una forma mentis precedente per essere apprezzata e sfruttata in pieno. Oppure, la pazienza di fare un percorso di apprendimento graduale.

Questo è l'aspetto che sembra sfuggire ai principianti che si chiedono come imparare Python senza studiare. Il punto è che non sembra loro possibile che fare un sito in Django debba essere più lento e complicato rispetto, per dire, a fare un sito in Wix. Oppure, che raccogliere dati con Scrapy debba richiedere uno sforzo di apprendimento maggiore che con Parsehub o Webscraper.io. E così via. Naturalmente non ho idea di quanti di costoro abbiano provato ambienti LCNC e possano fare il paragone con cognizione di causa.
Ma sospetto che almeno una buona parte arriva a Python aspettandosi la versione gratis di Delphi, a dirla tutta.

Per chiarire: non voglio dire che Python, negli anni, ha fatto "pubblicità ingannevole" di sé. Almeno all'inizio, la platea a cui si rivolgeva era perfettamente in grado di interpretare nel modo corretto gli aspetti di semplicità e usabilità che proponeva. Era gente che veniva da Perl, da Java, ovviamente da C++, tipicamente da Unix e dallo scripting di shell. Alcuni erano hacker.
Ma io sospetto che oggi questa pubblicità, involontariamente, abbia smesso di comunicare la cosa giusta. Forse oggi sarebbe più appropriato ricordare che Python resta comunque un linguaggio di programmazione e non un ambiente visuale, un linguaggio procedurale che non ammette troppe "libere aggregazioni" di elementi, un linguaggio orientato agli oggetti che richiede pur sempre una buona dose di cerimoniale sintattico.
Uno dei tool LCNC di cui abbiamo parlato si propone ai suoi utenti senza tanti giri di parole: "con noi è possibile costruire applicazioni che funzionano, senza tante str***ate". Ecco, se vogliamo usare questo termine, allora io credo che bisognerebbe ricordare: Python richiede pur sempre una modica quantità di str***ate.

Vent'anni dopo, le astrazioni continuano a perdere.

Con tutto questo non abbiamo ancora risposto completamente alla domanda iniziale. Che cosa vuol dire, quindi, che Python è "facile", se non è "facile da usare"? Perché non è possibile imparare Python senza studiare, o usare Python senza averlo imparato?

Ancora una volta conviene prendere spunto da una cosa pensata vent'anni fa. The Law of Leaking Abstractions (La legge delle astrazioni che perdono, gocciolano) è un famoso articolo di Joel Spolsky del 2002. La riflessione è che noi costruiamo livelli di astrazione via via più potenti e sofisticati perché sia più semplice manovrare gli oggetti sottostanti, che sono primitivi e complicati da usare. E queste astrazioni di solito funzionano, nel senso che davvero rendono i sistemi più facili da usare. Ma inevitabilmente prima o poi capiterà lo scenario in cui cui l'astrazione non tiene più, "ha una perdita" e ti lascia intravedere il complicato groviglio sottostante. E in questi casi a te non resta che scendere al piano di sotto, per così dire, e affrontare di nuovo quegli oggetti primitivi che l'astrazione cercava di semplificare. Il punto fondamentale della riflessione di Spolsky è che tutte le astrazioni "hanno una perdita" da qualche parte.

Prendiamo Python, per esempio. Quando volete aprire un file di testo, Python vi mette a disposizione un elegante livello di astrazione. Voi scrivete qualcosa come "with open("miofile.txt") as f:" e Python si occupa per voi di tutta la burocrazia dei puntatori C sottostanti. Vi restituisce un oggetto di alto livello, su cui è possibile iterare con un semplice "for", e che potete gestire comodamente con la variabile "f". Non solo: grazie al context manager, quando avete finito Python chiude il file per voi e distrugge anche la variabile dietro le quinte, senza che dobbiate preoccuparvi di deallocare a mano la memoria. Un lavoretto niente male per una sola riga di codice, vero?
Solo che questa astrazione arriva fino a un certo punto, poi comincia a perdere. Python non ha nessun modo di entrare nella vostra testa e capire dove si trova fisicamente il file "miofile.txt" nel file system gestito dal vostro sistema operativo. Tutto quello che può fare è accettare una path alla cieca, e sperare che quella path punti davvero a un file che accetta di essere aperto. E se la path è relativa (come il nostro "miofile.txt"), allora Python la risolve secondo le regole del file system, componendola con la directory corrente. E a sua volta, la directory corrente non dipende da Python, ma dall'ambiente di esecuzione esterno. E quindi può essere diversa se avete avviato lo script dalla shell, se ci avete fatto doppio clic sopra, se avete premuto "F5" o "Run" dal vostro editor...
Ed ecco che la vostra elegante astrazione vi ha già lasciato a piedi: e infatti, i forum sono pieni di principianti che chiedono "aiuto, non mi trova il file se eseguo da Idle!!!1!1!!!".

E in un certo senso il principiante non ha torto: ha visto una astrazione e ha pensato che fosse sinonimo di "facile da usare". Ma purtroppo le astrazioni non sono fatte per essere facili da usare: il loro scopo è un altro. Ci arriviamo, sempre accompagnati da Joel Spolsky, tra un minuto.

Ora, se io dovessi insegnare Python a un principiante, probabilmente all'inizio direi: se vuoi giocare con "open", metti tutti i tuoi file nella stessa directory dello script. E poi all'inizio dello script scrivi qualcosa come "import os, os.path; os.chdir(os.path.abspath(os.path.dirname(__file__)))". Non preoccuparti di che cosa vuol dire, per il momento. Fidati e basta.
Qual è il problema? Avete indovinato: questa è solo un'altra astrazione. Può essere utile per non confondere il principiante, ma prima o poi non c'è niente da fare: non si può usare "open" senza sapere anche qualcosa di come funziona il file system sottostante. "Open" è un'astrazione che perde.
E, d'altra parte, potrei continuare ad aggiungere astrazione dopo astrazione per facilitare il principiante, fino a costruire una vera e propria piattaforma didattica. Ma non sarebbe più possibile usarla per niente di serio.

E così il principiante che si avvicina a Python in cerca di "come Delphi, ma gratis" impazzisce di gioia quando scopre che esiste Qt Designer: ma dopo aver giocato un po' con il drag'n'drop, arriva inevitabilmente il momento in cui scopre che dietro questa gradevole astrazione esiste un grande, cattivo GUI framework C++, pieno di concetti complicati come "signal/slot", "loop degli eventi" e così via.
E sappiamo bene che Django Admin consente di creare "auto-magicamente" un sito di amministrazione per un'applicazione con database. Ma appena andate oltre questa specifica necessità, non vi resta che imparare con pazienza il linguaggio dei template di Django.
Ma poi, intendiamoci: anche creare un'applicazione con Delphi vi espone ben presto a tutto il Pascal sottostante. Anche creare un sito con Wix è facile se restate nell'ambito degli strumenti di Wix: ma se mettete il piede nel punto sbagliato, scoprite che dietro c'è tutto un framework da programmare a colpi di Javascript.

La morale dell'articolo di Joel Spolsky sulle astrazioni che perdono è talmente importante che vale la pena riportarla qui per esteso:
"La legge delle astrazioni che perdono significa che tutte le volte che qualcuno salta fuori con nuovo eccitante strumento di generazione del codice che dovrebbe renderci tutti molto più efficienti, sentirete molti che dicono: impara prima a farlo a mano, poi usa il nuovo eccitante strumento per risparmiare tempo. I generatori di codice che pretendono di mascherare la complessità, come tutte le astrazioni, prima o poi perdono; e l'unico modo di affrontare le perdite è imparare come funzionano le astrazioni, e che cosa stanno mascherando. E quindi, le astrazioni possono farci risparmiare tempo nel lavoro, ma non ci faranno risparmiare tempo nell'apprendere."

Si può imparare Python senza studiare?

L'ultima affermazione, per quanto scoraggiante, è semplicemente vera. Lo scopo delle astrazioni non è, come speravamo, permetterci di lavorare senza dover imparare... le str***ate, come si diceva sopra. Lo scopo delle astrazioni è permetterci di lavorare in modo più efficiente e affrontare problemi di complessità via via crescente.

Questo mette la questione "imparare o no" nella giusta prospettiva. Quaranta o cinquanta anni fa non c'erano grandi alternative. Il livello delle astrazioni era talmente basso (e l'accesso ai computer talmente ristretto) che le strade per diventare programmatori erano pochine: Guido ha una laurea in Matematica e Computer Science, per capirci. Poi certo, c'erano anche gli autodidatti: ma appunto, erano i tempi degli hacker. E l'etica hacker era definita appunto dalla passione inesauribile per apprendere, prima che per usare.

Oggi certamente non è più così... ma solo fino a un certo punto, perché poi le astrazioni iniziano a perdere. Ora, io non credo affatto che prima di scrivere la prima riga di Python uno debba avere una laurea in Matematica. Penso che si possa fare parecchia strada senza sapere come si implementa una lista di adiacenza. Penso che molti programmatori Python non avranno mai bisogno di implementarne una, in effetti.
Dirò di più: penso che molti corsi, anche universitari, sono tenuti oggi da docenti che visibilmente hanno scritto "Python" nel programma solo per attirare un po' di gente, ma in realtà hanno sempre insegnato C e vogliono continuare a insegnarlo. E cercano di costringere a martellate dentro Python dei pattern di programmazione che in realtà starebbero meglio in C (e poi ci sono quelli che invece vogliono insegnare Java, naturalmente). E quando gli esercizi che danno agli studenti ogni tanto finiscono nei forum, è tutto un fiorire di "puntatori", e di "array" per dire "liste". Questi docenti non stanno insegnando né C né Python.

(Detto questo, penso però che sapere come si implementa una lista di adiacenza ti dà un vantaggio competitivo non da poco nel mondo del lavoro, anche come programmatore Python. Ma questo è un altro aspetto, pur molto importante.)

In primo luogo, credo che al principiante andrebbe chiarito che si possono fare tante cose utili anche senza Python. Per lungo tempo Python è stato una porta per la programmazione rapida ed efficiente: un linguaggio per sviluppare prototipi, per esempio. Oggi spesso non è più così. Fare il prototipo di un sito in Wix in molti casi è più conveniente e rapido che farlo in Django. E, come sempre succede, quel prototipo in molti casi è già pronto per finire, a calci, in produzione. Se basta Wix, allora usate Wix. Oppure: Django Forms è molto potente, ma non è facilissimo da usare. Avete provato Google Forms? Magari in combinazione con Google Sites? Se quello che vi serve è un risultato, cercate di capire qual è lo strumento più rapido per ottenere quel risultato. Mantenetevi elastici.

Se invece volete lavorare con Python, allora prima di tutto dovreste essere disposti a investire del tempo senza la pretesa di ottenere alcun risultato. La cosa peggiore in assoluto è il principiante che a malapena sa che cosa è una funzione e già si mette in testa di scrivere una GUI o un sito web. Anche perché non riesci più a staccarlo dal suo malsano proposito: continuerà in eterno a picchiare a caso sulla tastiera e tempestare di messaggi i forum a ogni riga di codice che, inevitabilmente, "non gli funziona", chiedendo "spunti" (cioè, pezzi di codice da copiare e incollare) e lamentandosi che non lo si "vuole aiutare". Ecco, questa è la forma mentis peggiore di tutte. E anche la più diffusa, guarda un po'. Ed è anche la più naturale, purtroppo: come abbiamo visto, dipende dal fatto che molti principianti pensano che Python debba essere "facile" nel senso di "facile da usare". E come ormai sappiamo, la risposta è no: Python è facile in un senso completamente differente.

Se quindi volete lavorare con Python e siete disponibili a investirci del tempo senza pretese di risultati immediati, allora è difficile dire quanto poco basta sapere prima di cominciare con Python. Io penso che almeno qualcosa sulla shell del vostro sistema operativo bisognerebbe averla capita. Dopo di che, seguire un buon libro passo-passo dovrebbe bastare a procedere lentamente su un terreno abbastanza solido (il Lutz è sempre una buona idea, anche se in Italiano l'ultima edizione non è disponibile).
Ma la cosa più importante da ricordare è che Python è comunque solo un'astrazione che perde. Appena provate a mettere un piede fuori dal percorso didattico del libro che state seguendo, è normale che finirete su una mina. Non c'è niente di "semplice" in Python. Talvolta c'è più magia nera dietro un "print" Python che in molte righe di C++ (e non parliamo nemmeno di che cosa fa davvero Django dietro le quinte). Tutte le volte che finite su una mina, prendetelo come un segnale che non sapete davvero quello che c'è da sapere sull'argomento. Non incaponitevi a risolvere lo specifico problema su cui vi siete bloccati. Invece, fate un passo indietro e approfondite la vostra conoscenza sull'argomento in generale. Leggete la documentazione, più volte.

Soprattutto, quando trovate in giro una "ricetta" che risolve il vostro problema, non usatela! Mai! Per nessuna ragione! Invece, studiatela: capite perché funziona, scomponendola pezzo per pezzo. Poi allontanatela dallo sguardo, magari lasciate passare un giorno, e provate a ricostruirla con le vostre forze. Questo è l'unico modo di usare le "ricette" che trovate in giro o che qualche benintenzionato vi passa sul forum. Altrimenti, le "ricette" sono il principale motivo per cui non fate progressi e non ne farete mai.
Il motivo ormai dovrebbe essere chiaro: "risolvere un problema facilmente" e "un linguaggio facile da programmare" non sono sinonimi. Python è la seconda cosa, ma non permette davvero di fare la prima, nel senso che di solito intende il principiante.

E quindi, per concludere: è possibile imparare Python senza studiare? No. È possibile usare Python per ottenere dei risultati, senza studiare? Temo di no. Ma non è detto che capire non possa essere divertente, molto più di imparare e molto più di usare.