Newsgroup: it.comp.lang.delphi
Titolo: [OT] python come complemento a delphi

Sto utilizzando python da circa un mese per la scrittura di algoritmi, e 
mi chiedevo se qualcuno che l'ha provato lo possa ritenere un valido 
supporto, se non possibile sostituto, alla programmazione in Object 
pascal. (ad esclusione del disegno delle GUI, che non ho esplorato)
 
Ho trovato impressionante la velocità con la quale si producono dei 
prototipi, e l'intrinseca facilità di debugging di un'ambiente interpretato.
 
Le performances (utilizzando pypy come compilatore, 
http://pypy.org/
) 
sono vicine a quelle di un compilato C++: preciso che sto parlando di 
algoritmi, non di programmi GUI based)
 
Mi è piaciuto inoltre l'approccio di non dover dichiarare a priori il 
tipo di dato delle variabili (ma, all'occorrenza, si può sempre specificare)
 
Mi chiedo se magari qualcuno si sta interfacciando già con python, a 
questo link ci sono i binding con le dll: 
https://code.google.com/p/python4delphi/
 
 
Per iniziare sono partito da questo sito (ottimo, imho): 
http://www.codecademy.com/en/tracks/python
 
 
-- 
Morde

 
https://code.google.com/p/python4delphi/
 
 
Piu che cosi, la mia idea era usarlo come linguaggio di scripting per "aprire" una app delphi alla esecuzione di codice definito a runtime.
 
A.

 "aprire" una app delphi alla esecuzione di codice definito a runtime.
 
Beh, Python puo` essere utilizzato per svariate attivita`, 
dall'automatizzazione di attivita` (scripting) alla creazione di webapp 
abbastanza pesanti. Personalmente lo uso un po' per tutto, dallo scriptare 
il trasferimento dati da un database ad un altro, alla creazione di servizi 
REST :)
 
Un Enrico Javista, Pythonista e Gopher (ma che non disdegna Delphi) ;)

 Un Enrico Javista, Pythonista e Gopher (ma che non disdegna Delphi) ;)
 
Io mi sto avvicinando a PHP e lavoro occasionalmente in c#.
E non disdegno un buon bicchiere di rosso, una serata con amici a fare 'o burdello e ovviamente le donne. :-D
 
A.

 Io non lo farei. Se usi una variabile prima come int poi come stringa o altro alla 
 > fine si corre il rischio di fare un casino bestiale, come accadeva in
 > clipper.
 
 
perfettamente d'accordo. Secondo me la non tipizzazione delle variabili 
alla lunga può dare solo problemi, magari in piccoli pezzi di codice è 
comoda ma credo che la velocità di esecuzione del codice ne risentirebbe 
e non poco.
 
 
 
-- 
-------------------------------
per scrivere in privato
togliere "1975nosp"
 
to reply remove "1975nosp"
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
http://www.avast.com
 
 

>> 
 
Inoltre, sempre per il discorso del siamo adulti (e del Explicit is better 
than implicit), considera che nella definizione delle classi in Python il 
concetto di metodo privato non esiste (in teoria c'e` il modo per emularli, 
ma e` semplicemente un sistema per rendere univoci i metodi e le variabili 
in una serie di classi ereditate)
 
Enrico

>> 
 
Occhio, che e` facile associare la tipizzazione forte con la tipizzazione 
statica. Ad esempio di cio`, faccio notare che convenzionalmente C e` 
definito come linguaggio a tipizzazione statica ma debole, mentre 
Pascal/Delphi e` un linguaggio a tipizzazione statica ma forte
 
Enrico

 Io non lo farei. Se usi una variabile prima come int poi come stringa o altro alla fine si corre il rischio di fare un casino bestiale, come accadeva in clipper.
 
E' l'aspetto che distingue i linguaggi dinamici dagli altri e dipende ovviamente dal contesto di cui si parla, anche perché se lo spauracchio è il "casino bestiale", ci sono migliaia e migliaia di modi di ottenerlo anche con qualsiasi linguaggio fortemente tipizzato. :)
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
 #Home: 
http://www.marco.breveglieri.name
 
 #Blog: 
http://www.compilaquindiva.com
 
 #DelphiPodcast: 
http://www.delphipodcast.com
 

 Pascal/Delphi e` un linguaggio a tipizzazione statica ma forte
 
Enrico,
concordo con quanto espresso da te fin d'ora.
All'inizio mi ero trovato spiazzato: abituato a dichiarare i tipi per 
vent'anni, non è stato facile cambiare il paradigma.
Una volta abituato, ora procedo spedito e la velocità di sviluppo è 
elevatissima.
 
Bisogna inoltre distinguere il campo d'applicazione, come faceva notare 
Marco nel thread: io lavoro su dati scientifici e scrivo algoritmi, 
attività prettamente di scripting, e questo favorisce la velocità.
 
Non mi devo occupare di gestire GUI (per fortuna). Però, so che ci sono 
i binding per le varie librerie grafiche, Qt ad esempio, che sto usando 
con C++: sarebbe interessante provare a sviluppare una GUI in Qt con 
python..
 
-- 
Morde

 sarebbe interessante provare a sviluppare una GUI in Qt con python..
 
E` abbastanza simile in C++ (da uno dei tutorial in circolazione):
 
import sys
from PyQt4 import QtGui
 
 
def main():
 
    app = QtGui.QApplication(sys.argv)
 
    w = QtGui.QWidget()
    w.resize(250, 150)
    w.move(300, 300)
    w.setWindowTitle('Simple')
    w.show()
 
    sys.exit(app.exec_())
 
 
if __name__ == '__main__':
    main()
 
Enrico

Enrico Bianchi ha scritto:

Non conosco python quindi per curiosità chiedo, ma "app" e "w" sono 
dichiarati o no?
 
Se io per errore avessi scritto una cosa simile, si sarebbe accorto? 
spero sia giusta la sintassi altrimenti pazienza.
gli errori dovrebbero essere, in un caso ho scritto posyy ( riga 1 ), 
nella riga 3 con una sola y (posy), è un errore banale ma in molti casi 
difficile da trovare, se la dichiarazione non fosse obbligatoria, vero 
che posso avere variabili con nomi simili e confondere...
 
Il v.move credo che non essendo un oggetto lo veda subito.
 
posyy=100
w = QtGui.QWidget()
w.resize(250, posy)
v.move(300, 300)
w.setWindowTitle('Simple')
w.show()
 


 e non poco.
 
Se solo la gente sapesse di che cosa sta parlando, prima di dare fiato alle dita: 
https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
 
 

>> 
 
Enrico
[1] In teoria il discorso e` un po' differente, ma il risultato e` quello 
che ti aspetti, ovvero avere un valore in una variabile