Voila quelques jours que j'ai commencé avec python et j'ai du mal à
m'adapter.
La boucle for, les listes,...
Bon ça fait partie du language donc à moi de m'adapter, et c'est aps
evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est
executé sans etre verifié. Donc parfois quand le traitement est long
lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se
produit. Ce qui est penible.
Le dernier en date, un doublon de fonction, suite a un copié collé par
erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath
ne me renvoyait rien. La fonction que je modifiais n'etait pas celle
qui etait executée. Et pas de message d'avertissement. Pas mal de
temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
tu peux essayer de lancer pylint sur ton script. Il peut te donner des indications sur la qualité de ton code. Pour le problème dont tu parles tu auras une ligne comme celle-là:
E: 5:test: function already defined line 2
http://www.logilab.org/857
On Aug 11, 4:21 pm, Baton Rouge wrote:
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié. Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible. Le dernier en date, un doublon de fonction, suite a un copié collé pa r erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou fair e un malaise vagal et creuser le trou de la sécu ?
Bonjour,
tu peux essayer de lancer pylint sur ton script. Il peut te donner
des indications sur la qualité de ton code. Pour le problème dont tu
parles tu auras une ligne comme celle-là:
E: 5:test: function already defined line 2
http://www.logilab.org/857
On Aug 11, 4:21 pm, Baton Rouge <nos...@poubelle.con> wrote:
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à
m'adapter.
La boucle for, les listes,...
Bon ça fait partie du language donc à moi de m'adapter, et c'est aps
evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est
executé sans etre verifié. Donc parfois quand le traitement est long
lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se
produit. Ce qui est penible.
Le dernier en date, un doublon de fonction, suite a un copié collé pa r
erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath
ne me renvoyait rien. La fonction que je modifiais n'etait pas celle
qui etait executée. Et pas de message d'avertissement. Pas mal de
temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou fair e un malaise vagal et creuser le trou de la sécu ?
tu peux essayer de lancer pylint sur ton script. Il peut te donner des indications sur la qualité de ton code. Pour le problème dont tu parles tu auras une ligne comme celle-là:
E: 5:test: function already defined line 2
http://www.logilab.org/857
On Aug 11, 4:21 pm, Baton Rouge wrote:
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié. Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible. Le dernier en date, un doublon de fonction, suite a un copié collé pa r erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou fair e un malaise vagal et creuser le trou de la sécu ?
Alain Ketterlin
Baton Rouge writes:
Y a une solution de verification avant chaque execution ?
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié. Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible.
Faites sorte de valider votre code d'abord avec des données débouchant sur un traitement court.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée.
J'ai eu ça en C ou en assembleur il y a quelques années. J'oubliais de sauvegarder, utilisant un éditeur tout en étant habitué à un IDE. Depuis, j'ai augmenté mes exigences quant à un IDE ou un éditeur de développement. Et quand je commence à tourner en rond, la première chose que je fais, c'est d'imprimer un texte qui change à chaque essai. Utile en Web, sur des tranferts FTP flemmards ou des navigateurs trop attachés à leur cache.
Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
Eclipse / Pydev signale à la frappe beaucoup d'erreurs. Section "Code analysis". De plus cet IDE intègre en un clic la vérification par Pylint.
Remarquez que votre double définition ne peut pas être une erreur en Python, sinon Python ne serait pas Python. Ecrire:
def test(): return 1 #.... def test(): return 2
c'est la même chose qu'écrire:
a = 10 #.... a = 12
Si vous utilisez la vue /Outline/ de Eclipse / Pydev, en tri alphabétique, ce qui est une bonne pratique, ces doublons ne pourront vous échapper.
-- Pierre Maurette
Baton Rouge, le 11/08/2010 a écrit :
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à
m'adapter.
La boucle for, les listes,...
Bon ça fait partie du language donc à moi de m'adapter, et c'est aps
evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est
executé sans etre verifié. Donc parfois quand le traitement est long
lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se
produit. Ce qui est penible.
Faites sorte de valider votre code d'abord avec des données débouchant
sur un traitement court.
Le dernier en date, un doublon de fonction, suite a un copié collé par
erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath
ne me renvoyait rien. La fonction que je modifiais n'etait pas celle
qui etait executée.
J'ai eu ça en C ou en assembleur il y a quelques années. J'oubliais de
sauvegarder, utilisant un éditeur tout en étant habitué à un IDE.
Depuis, j'ai augmenté mes exigences quant à un IDE ou un éditeur de
développement. Et quand je commence à tourner en rond, la première
chose que je fais, c'est d'imprimer un texte qui change à chaque essai.
Utile en Web, sur des tranferts FTP flemmards ou des navigateurs trop
attachés à leur cache.
Et pas de message d'avertissement. Pas mal de
temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
Eclipse / Pydev signale à la frappe beaucoup d'erreurs. Section "Code
analysis". De plus cet IDE intègre en un clic la vérification par
Pylint.
Remarquez que votre double définition ne peut pas être une erreur en
Python, sinon Python ne serait pas Python. Ecrire:
def test():
return 1
#....
def test():
return 2
c'est la même chose qu'écrire:
a = 10
#....
a = 12
Si vous utilisez la vue /Outline/ de Eclipse / Pydev, en tri
alphabétique, ce qui est une bonne pratique, ces doublons ne pourront
vous échapper.
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié. Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible.
Faites sorte de valider votre code d'abord avec des données débouchant sur un traitement court.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée.
J'ai eu ça en C ou en assembleur il y a quelques années. J'oubliais de sauvegarder, utilisant un éditeur tout en étant habitué à un IDE. Depuis, j'ai augmenté mes exigences quant à un IDE ou un éditeur de développement. Et quand je commence à tourner en rond, la première chose que je fais, c'est d'imprimer un texte qui change à chaque essai. Utile en Web, sur des tranferts FTP flemmards ou des navigateurs trop attachés à leur cache.
Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
Eclipse / Pydev signale à la frappe beaucoup d'erreurs. Section "Code analysis". De plus cet IDE intègre en un clic la vérification par Pylint.
Remarquez que votre double définition ne peut pas être une erreur en Python, sinon Python ne serait pas Python. Ecrire:
def test(): return 1 #.... def test(): return 2
c'est la même chose qu'écrire:
a = 10 #.... a = 12
Si vous utilisez la vue /Outline/ de Eclipse / Pydev, en tri alphabétique, ce qui est une bonne pratique, ces doublons ne pourront vous échapper.
-- Pierre Maurette
Michel Claveau - MVP
Bonsoir !
En fait, il y a une vérification, au lancement de l'exécution. Cette vérification porte essentiellement sur la syntaxe.
Pour le reste, et comme l'a dit Pierre Maurette, il y a des points qui peuvent être, soit des erreurs, soit normale, selon le besoin. Par exemple :
if os.name=='nt': def iswindows(): return(True) else: def iswindows(): return(False)
Il y a deux déclarations d'une fonction, mais c'est parfaitement voulu. Un autre usage (plus courant), c'est de redéfinir une fonction (ou d' une méthode) en cours d'exécution.
@+ -- MCi
Bonsoir !
En fait, il y a une vérification, au lancement de l'exécution.
Cette vérification porte essentiellement sur la syntaxe.
Pour le reste, et comme l'a dit Pierre Maurette, il y a des points
qui peuvent être, soit des erreurs, soit normale, selon le
besoin.
Par exemple :
if os.name=='nt':
def iswindows():
return(True)
else:
def iswindows():
return(False)
Il y a deux déclarations d'une fonction, mais c'est parfaitement voulu.
Un autre usage (plus courant), c'est de redéfinir une fonction (ou d'
une méthode) en cours d'exécution.
En fait, il y a une vérification, au lancement de l'exécution. Cette vérification porte essentiellement sur la syntaxe.
Pour le reste, et comme l'a dit Pierre Maurette, il y a des points qui peuvent être, soit des erreurs, soit normale, selon le besoin. Par exemple :
if os.name=='nt': def iswindows(): return(True) else: def iswindows(): return(False)
Il y a deux déclarations d'une fonction, mais c'est parfaitement voulu. Un autre usage (plus courant), c'est de redéfinir une fonction (ou d' une méthode) en cours d'exécution.
@+ -- MCi
Bruno Desthuilliers
Baton Rouge a écrit :
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié.
La syntaxe est vérifiée. Pour le reste, tout se passe à l'exécution effectivement.
Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible.
Un langage statique ne détecte pas non plus toutes les erreurs - et particulièrement pas les plus gênantes - les erreurs de logique.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement.
Aucune raison qu'il y ait un message d'avertissement. Les fonctions Python sont des objets commes les autres, et il est parfaitement légal (et légitime) de vouloir redéfinir une fonction. C'est d'ailleurs ce que font les décorateurs.
Pas mal de temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
Non. Mais il y a d'une part des outils d'analyse de code (pylint, pychecker etc) qui peuvent attirer ton attention sur des problèmes potentiels, et d'autre part des outils de test unitaire qui permettent de vérifier que le code fonctionne comme prévu.
Baton Rouge a écrit :
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à
m'adapter.
La boucle for, les listes,...
Bon ça fait partie du language donc à moi de m'adapter, et c'est aps
evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est
executé sans etre verifié.
La syntaxe est vérifiée. Pour le reste, tout se passe à l'exécution
effectivement.
Donc parfois quand le traitement est long
lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se
produit. Ce qui est penible.
Un langage statique ne détecte pas non plus toutes les erreurs - et
particulièrement pas les plus gênantes - les erreurs de logique.
Le dernier en date, un doublon de fonction, suite a un copié collé par
erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath
ne me renvoyait rien. La fonction que je modifiais n'etait pas celle
qui etait executée. Et pas de message d'avertissement.
Aucune raison qu'il y ait un message d'avertissement. Les fonctions
Python sont des objets commes les autres, et il est parfaitement légal
(et légitime) de vouloir redéfinir une fonction. C'est d'ailleurs ce que
font les décorateurs.
Pas mal de
temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
Non. Mais il y a d'une part des outils d'analyse de code (pylint,
pychecker etc) qui peuvent attirer ton attention sur des problèmes
potentiels, et d'autre part des outils de test unitaire qui permettent
de vérifier que le code fonctionne comme prévu.
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié.
La syntaxe est vérifiée. Pour le reste, tout se passe à l'exécution effectivement.
Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible.
Un langage statique ne détecte pas non plus toutes les erreurs - et particulièrement pas les plus gênantes - les erreurs de logique.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement.
Aucune raison qu'il y ait un message d'avertissement. Les fonctions Python sont des objets commes les autres, et il est parfaitement légal (et légitime) de vouloir redéfinir une fonction. C'est d'ailleurs ce que font les décorateurs.
Pas mal de temps de perdu et des @#$%grrr
Y a une solution de verification avant chaque execution ?
Non. Mais il y a d'une part des outils d'analyse de code (pylint, pychecker etc) qui peuvent attirer ton attention sur des problèmes potentiels, et d'autre part des outils de test unitaire qui permettent de vérifier que le code fonctionne comme prévu.
Baton Rouge
On Fri, 13 Aug 2010 10:43:02 +0200, Bruno Desthuilliers wrote:
Y a une solution de verification avant chaque execution ?
Non. Mais il y a d'une part des outils d'analyse de code (pylint, pychecker etc) qui peuvent attirer ton attention sur des problèmes potentiels, et d'autre part des outils de test unitaire qui permettent de vérifier que le code fonctionne comme prévu.
Venant de delphi c'est deroutant. Mais je viens de voir que delphi à un plugin pour traiter le python dans son IDE.
quelqu'un a déjà essayé ? http://www.atug.com/andypatterns/pythonDelphiTalk.htm
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Fri, 13 Aug 2010 10:43:02 +0200, Bruno Desthuilliers
<bruno.42.desthuilliers@websiteburo.invalid> wrote:
Y a une solution de verification avant chaque execution ?
Non. Mais il y a d'une part des outils d'analyse de code (pylint,
pychecker etc) qui peuvent attirer ton attention sur des problèmes
potentiels, et d'autre part des outils de test unitaire qui permettent
de vérifier que le code fonctionne comme prévu.
Venant de delphi c'est deroutant. Mais je viens de voir que delphi à
un plugin pour traiter le python dans son IDE.
quelqu'un a déjà essayé ?
http://www.atug.com/andypatterns/pythonDelphiTalk.htm
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Fri, 13 Aug 2010 10:43:02 +0200, Bruno Desthuilliers wrote:
Y a une solution de verification avant chaque execution ?
Non. Mais il y a d'une part des outils d'analyse de code (pylint, pychecker etc) qui peuvent attirer ton attention sur des problèmes potentiels, et d'autre part des outils de test unitaire qui permettent de vérifier que le code fonctionne comme prévu.
Venant de delphi c'est deroutant. Mais je viens de voir que delphi à un plugin pour traiter le python dans son IDE.
quelqu'un a déjà essayé ? http://www.atug.com/andypatterns/pythonDelphiTalk.htm
-- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
Mickaël Wolff
Le 14/08/2010 13:34, Baton Rouge a écrit :
Venant de delphi c'est deroutant. Mais je viens de voir que delphi à un plugin pour traiter le python dans son IDE.
Moi aussi j'aime beaucoup a résolution statique des types, mais dans un langage dynamique, ce n'est pas adapté, ça ne fait pas partie de l'idiome choisi.
En contre-partie, tu peux te mettre aux tests unitaires <http://docs.python.org/library/unittest.html>. Les tests unitaires te permettent d'exprimer le contrat que tes fonctions et classes rempliront. Les tests unitaires permettent aussi de s'assurer que l'évolutuon du code ne cassera pas le code client de tes fonctions, en continuant à remplir leur contrat (vérifié en lançant les script). C'est assez similaire à la phase de résolution statique des variables, mais en plus puissant. La résolution statique permet de vérifier que l'interface est conforme à ce qui a été décidé, et que les clients l'utilisent comme spécifié. Les tests unitaires peuvent vérifier ça *et* le comportement de la fonction. C'est pourquoi, dans les langages compilés aussi, les tests unitaires sont adoptés.
Ceci dit, si tu veux un typage statique, change de langage. PHP vient de l'introduire pour les types scalaires (c'était le troll venu du WE).
Venant de delphi c'est deroutant. Mais je viens de voir que delphi à
un plugin pour traiter le python dans son IDE.
Moi aussi j'aime beaucoup a résolution statique des types, mais dans
un langage dynamique, ce n'est pas adapté, ça ne fait pas partie de
l'idiome choisi.
En contre-partie, tu peux te mettre aux tests unitaires
<http://docs.python.org/library/unittest.html>. Les tests unitaires te
permettent d'exprimer le contrat que tes fonctions et classes
rempliront. Les tests unitaires permettent aussi de s'assurer que
l'évolutuon du code ne cassera pas le code client de tes fonctions, en
continuant à remplir leur contrat (vérifié en lançant les script).
C'est assez similaire à la phase de résolution statique des
variables, mais en plus puissant. La résolution statique permet de
vérifier que l'interface est conforme à ce qui a été décidé, et que les
clients l'utilisent comme spécifié. Les tests unitaires peuvent vérifier
ça *et* le comportement de la fonction. C'est pourquoi, dans les
langages compilés aussi, les tests unitaires sont adoptés.
Ceci dit, si tu veux un typage statique, change de langage. PHP vient
de l'introduire pour les types scalaires (c'était le troll venu du WE).
Venant de delphi c'est deroutant. Mais je viens de voir que delphi à un plugin pour traiter le python dans son IDE.
Moi aussi j'aime beaucoup a résolution statique des types, mais dans un langage dynamique, ce n'est pas adapté, ça ne fait pas partie de l'idiome choisi.
En contre-partie, tu peux te mettre aux tests unitaires <http://docs.python.org/library/unittest.html>. Les tests unitaires te permettent d'exprimer le contrat que tes fonctions et classes rempliront. Les tests unitaires permettent aussi de s'assurer que l'évolutuon du code ne cassera pas le code client de tes fonctions, en continuant à remplir leur contrat (vérifié en lançant les script). C'est assez similaire à la phase de résolution statique des variables, mais en plus puissant. La résolution statique permet de vérifier que l'interface est conforme à ce qui a été décidé, et que les clients l'utilisent comme spécifié. Les tests unitaires peuvent vérifier ça *et* le comportement de la fonction. C'est pourquoi, dans les langages compilés aussi, les tests unitaires sont adoptés.
Ceci dit, si tu veux un typage statique, change de langage. PHP vient de l'introduire pour les types scalaires (c'était le troll venu du WE).
On Sat, 14 Aug 2010 22:02:36 +0100, Mickaël Wolff wrote:
Ceci dit, si tu veux un typage statique, change de langage. PHP vient de l'introduire pour les types scalaires (c'était le troll venu du WE).
Le probleme c'est que beaucoup de script sous ubuntu sont en python, donc passer à php c'est pas une bonne idee.
je connais pas suffisament python pour savoir si pythonDelphiTalk est une bonne solution.
Quand j'aurrai le temps, je testerai -- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Sat, 14 Aug 2010 22:02:36 +0100, Mickaël Wolff
<mickael.wolff@laposte.net> wrote:
Ceci dit, si tu veux un typage statique, change de langage. PHP vient
de l'introduire pour les types scalaires (c'était le troll venu du WE).
Le probleme c'est que beaucoup de script sous ubuntu sont en python,
donc passer à php c'est pas une bonne idee.
je connais pas suffisament python pour savoir si pythonDelphiTalk est
une bonne solution.
Quand j'aurrai le temps, je testerai
--
Travailler plus pour gagner plus pour quoi faire ?
Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
On Sat, 14 Aug 2010 22:02:36 +0100, Mickaël Wolff wrote:
Ceci dit, si tu veux un typage statique, change de langage. PHP vient de l'introduire pour les types scalaires (c'était le troll venu du WE).
Le probleme c'est que beaucoup de script sous ubuntu sont en python, donc passer à php c'est pas une bonne idee.
je connais pas suffisament python pour savoir si pythonDelphiTalk est une bonne solution.
Quand j'aurrai le temps, je testerai -- Travailler plus pour gagner plus pour quoi faire ? Pour finir par divorcer parce qu'on est pas souvent à la maison ou faire un malaise vagal et creuser le trou de la sécu ?
William Dode
On 11-08-2010, Baton Rouge wrote:
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié.
Mais il est vérifié ! Essayes de faire une erreur de syntaxe et compile ton code, tu le verras tout de suite.
Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible.
Quelque soit le langage. Si tu fais i=i+1 au lieu de i=i-1 tu n'auras une erreur qu'à l'exécution.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
L'erreur est humaine. Ce que tu considère une erreur est une possibilité avancée du langage. Comment voudrais-tu qu'un quelconque compilateur sache si tu redéfinis une fonction volontairement ou non (ce qui n'a rien d'exceptionnel en python) ?
Imagine que tu écrives i=i+1 et que le compilateur te dise systématiquement : attention êtes-vous bien sûr de vouloir changer la valeur de i ?
Y a une solution de verification avant chaque execution ?
Les tests unitaires, et ce n'est sûrement pas une machine qui devinera ce que ton programme est censé faire...
Bonne exploration...
-- William Dodé - http://flibuste.net Informaticien Indépendant
On 11-08-2010, Baton Rouge wrote:
bonjour
Voila quelques jours que j'ai commencé avec python et j'ai du mal à
m'adapter.
La boucle for, les listes,...
Bon ça fait partie du language donc à moi de m'adapter, et c'est aps
evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est
executé sans etre verifié.
Mais il est vérifié ! Essayes de faire une erreur de syntaxe et compile
ton code, tu le verras tout de suite.
Donc parfois quand le traitement est long
lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se
produit. Ce qui est penible.
Quelque soit le langage. Si tu fais i=i+1 au lieu de i=i-1 tu n'auras
une erreur qu'à l'exécution.
Le dernier en date, un doublon de fonction, suite a un copié collé par
erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath
ne me renvoyait rien. La fonction que je modifiais n'etait pas celle
qui etait executée. Et pas de message d'avertissement. Pas mal de
temps de perdu et des @#$%grrr
L'erreur est humaine. Ce que tu considère une erreur est une possibilité
avancée du langage. Comment voudrais-tu qu'un quelconque compilateur
sache si tu redéfinis une fonction volontairement ou non (ce qui n'a
rien d'exceptionnel en python) ?
Imagine que tu écrives i=i+1 et que le compilateur te dise
systématiquement : attention êtes-vous bien sûr de vouloir changer la
valeur de i ?
Y a une solution de verification avant chaque execution ?
Les tests unitaires, et ce n'est sûrement pas une machine qui devinera
ce que ton programme est censé faire...
Bonne exploration...
--
William Dodé - http://flibuste.net
Informaticien Indépendant
Voila quelques jours que j'ai commencé avec python et j'ai du mal à m'adapter. La boucle for, les listes,... Bon ça fait partie du language donc à moi de m'adapter, et c'est aps evident car ça me parrait tres pythonnesque.
Par contre, il y a un truc qui de herisse, c'est que le code est executé sans etre verifié.
Mais il est vérifié ! Essayes de faire une erreur de syntaxe et compile ton code, tu le verras tout de suite.
Donc parfois quand le traitement est long lors de l'execution, on s'appercoit qu'il y a une erreur quand elle se produit. Ce qui est penible.
Quelque soit le langage. Si tu fais i=i+1 au lieu de i=i-1 tu n'auras une erreur qu'à l'exécution.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
L'erreur est humaine. Ce que tu considère une erreur est une possibilité avancée du langage. Comment voudrais-tu qu'un quelconque compilateur sache si tu redéfinis une fonction volontairement ou non (ce qui n'a rien d'exceptionnel en python) ?
Imagine que tu écrives i=i+1 et que le compilateur te dise systématiquement : attention êtes-vous bien sûr de vouloir changer la valeur de i ?
Y a une solution de verification avant chaque execution ?
Les tests unitaires, et ce n'est sûrement pas une machine qui devinera ce que ton programme est censé faire...
Bonne exploration...
-- William Dodé - http://flibuste.net Informaticien Indépendant
Mickaël Wolff
Le 15/08/2010 14:02, William Dode a écrit :
Mais il est vérifié ! Essayes de faire une erreur de syntaxe et compile ton code, tu le verras tout de suite.
Tu as très bien compris ce qu'il a voulu dire. Il ne pense pas à la vérification de la syntaxe, mais à la validité du code.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
L'erreur est humaine. Ce que tu considère une erreur est une possibilité avancée du langage. Comment voudrais-tu qu'un quelconque compilateur sache si tu redéfinis une fonction volontairement ou non (ce qui n'a rien d'exceptionnel en python) ?
Avec un mot clé comme overwrite? :D Plus prosaiquement, on peut très bien contraindre un comportement strict en Python. En utilisant des décorateurs de classe par exemple, ce qui permet de contrôler l'ajout de fonctions dans le scope de la classe.
Imagine que tu écrives i=i+1 et que le compilateur te dise systématiquement : attention êtes-vous bien sûr de vouloir changer la valeur de i ?
Du toute façon, ici le compilateur devrait râler à cause de la répétition de i.
Y a une solution de verification avant chaque execution ?
Les tests unitaires, et ce n'est sûrement pas une machine qui devinera ce que ton programme est censé faire...
Et eventuellement mettre en place des outils de debug, comme des décorateurs qui contrôlent le typage des arguments, des retour de fonction, la surcharge de fonction, etc
Mais il est vérifié ! Essayes de faire une erreur de syntaxe et compile
ton code, tu le verras tout de suite.
Tu as très bien compris ce qu'il a voulu dire. Il ne pense pas à la
vérification de la syntaxe, mais à la validité du code.
Le dernier en date, un doublon de fonction, suite a un copié collé par
erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath
ne me renvoyait rien. La fonction que je modifiais n'etait pas celle
qui etait executée. Et pas de message d'avertissement. Pas mal de
temps de perdu et des @#$%grrr
L'erreur est humaine. Ce que tu considère une erreur est une possibilité
avancée du langage. Comment voudrais-tu qu'un quelconque compilateur
sache si tu redéfinis une fonction volontairement ou non (ce qui n'a
rien d'exceptionnel en python) ?
Avec un mot clé comme overwrite? :D Plus prosaiquement, on peut très
bien contraindre un comportement strict en Python. En utilisant des
décorateurs de classe par exemple, ce qui permet de contrôler l'ajout de
fonctions dans le scope de la classe.
Imagine que tu écrives i=i+1 et que le compilateur te dise
systématiquement : attention êtes-vous bien sûr de vouloir changer la
valeur de i ?
Du toute façon, ici le compilateur devrait râler à cause de la
répétition de i.
Y a une solution de verification avant chaque execution ?
Les tests unitaires, et ce n'est sûrement pas une machine qui devinera
ce que ton programme est censé faire...
Et eventuellement mettre en place des outils de debug, comme des
décorateurs qui contrôlent le typage des arguments, des retour de
fonction, la surcharge de fonction, etc
Mais il est vérifié ! Essayes de faire une erreur de syntaxe et compile ton code, tu le verras tout de suite.
Tu as très bien compris ce qu'il a voulu dire. Il ne pense pas à la vérification de la syntaxe, mais à la validité du code.
Le dernier en date, un doublon de fonction, suite a un copié collé par erreur. Sur le coup je ne comprenais pas pourquoi un traitement xpath ne me renvoyait rien. La fonction que je modifiais n'etait pas celle qui etait executée. Et pas de message d'avertissement. Pas mal de temps de perdu et des @#$%grrr
L'erreur est humaine. Ce que tu considère une erreur est une possibilité avancée du langage. Comment voudrais-tu qu'un quelconque compilateur sache si tu redéfinis une fonction volontairement ou non (ce qui n'a rien d'exceptionnel en python) ?
Avec un mot clé comme overwrite? :D Plus prosaiquement, on peut très bien contraindre un comportement strict en Python. En utilisant des décorateurs de classe par exemple, ce qui permet de contrôler l'ajout de fonctions dans le scope de la classe.
Imagine que tu écrives i=i+1 et que le compilateur te dise systématiquement : attention êtes-vous bien sûr de vouloir changer la valeur de i ?
Du toute façon, ici le compilateur devrait râler à cause de la répétition de i.
Y a une solution de verification avant chaque execution ?
Les tests unitaires, et ce n'est sûrement pas une machine qui devinera ce que ton programme est censé faire...
Et eventuellement mettre en place des outils de debug, comme des décorateurs qui contrôlent le typage des arguments, des retour de fonction, la surcharge de fonction, etc
