Ou alors, il a un mauvais prof (=> changer le prof ! )
Ou alors, il a un mauvais prof (=> changer le prof ! )
Ou alors, il a un mauvais prof (=> changer le prof ! )
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?) ou
se met à faire n'importe quoi (beaucoup plus difficile à déboguer)
En tout cas je viens toute juste de faire ma première petite application
en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer de la
programmation il n'y a pas mieux...)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?) ou
se met à faire n'importe quoi (beaucoup plus difficile à déboguer)
En tout cas je viens toute juste de faire ma première petite application
en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer de la
programmation il n'y a pas mieux...)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?) ou
se met à faire n'importe quoi (beaucoup plus difficile à déboguer)
En tout cas je viens toute juste de faire ma première petite application
en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer de la
programmation il n'y a pas mieux...)
Pourrais-tu rentrer un peu plus dans les détails ?
J'ai eu 2 pb au niveau de Python 23 lui-même :
- Dès qu'un code-source contenait des caractères accentués,
j'avais un
"warning" (non-bloquant) ; ma solution précédente (au niveau de site),
ne fonctionnait plus, et j'ai mis plusieurs heures à trouver qu'il
fallait ajouter # -*- coding: cp1252 -*- au début de mon code.
- Plus gênant : j'utilise un serveur COM (en Python), pour ajouter
des
fonctionnalités à mes logiciels Windows. Les paramètres sont passés en
unicode. La récupération des paramètres dans Python ne marchait plus.
Il a fallut que refasse un encodage différent, dès réception des
paramètres.
Tout n'est d'ailleurs pas réglé, car, par exemple, un simple :
print "Aïe"
exécuté en invite de commande windows (console) n'affiche pas le "i
tréma" normalement. Il faut faire un truc du genre :
print "Aïe".decode('cp1252')
Ce qui est quand même un poil gênant. A noter que, dans windows
lui-même, il n'y a pas de problème.
Concernant les modules externes, difficile de s'en passer, tant il en
existe. C'est d'ailleurs une des forces de Python. Cependant, il
arrivait qu'un module prévu pour Python2.2 ne fonctionnait pas sous
Python2.3. Il fallait donc attendre la disponibilité du module dans
cette version.
Or, j'ai dû renoncer à quelques modules, qui n'étaient
plus suivis. Dès lors se pose la question du choix des modules (et
outils). Avec deux critères : la pérennité, et la réactivité.
Un exemple : Boa-constructor. Bel outil, impressionnant. Et pourtant,
il ne fonctionne pas avec la dernière version de wxPython, pourtant
sortie depuis plusieurs mois. Du coup, comme la visibilité est trop
réduite, j'ai laissé tomber.
Ceci dit, ce problème n'est pas propre à Python.
Ca m'embêterait de devoir recoder sans cesse une interface
graphique lorsque je passe à la version supérieure
Oui, je suis dans le même cas. Mais Python étant Python, j'ai aperçu
le moyen de définir des niveaux d'abstraction intermédiaires, qui
limiteront les modifications nécessaires à, seulement, quelques points
de passage. Il faut, aussi, que je regarde la surcouche wax (
http://wiki.wxpython.org/index.cgi/Wax )
en entreprise, on me regarde avec des gros yeux quand j'en
parle...
Là, il faut le prendre de haut. Que quelqu'un ne pratique pas, ou
n'utilise pas, Python, soit. Mais ne pas en avoir entendu parler
prouve une incompétence flagrante.
Cela montre que la personne n'est pas au courant des technologies de
l'informatique.
Le gros problème de Python, en entreprise, c'est qu'il est libre. La
foule des commerciaux qui assiège les directions ne parlent que de ce
qui se VEND, d'où une occultation des autres solutions.
Perso, j'ai la chance de pouvoir imposer mes choix, en ne proposant
que des solutions. Mais, au vu des possibilités que je leur offre, les
clients en(re)-connaissent vite l'intérêt.
Pourrais-tu rentrer un peu plus dans les détails ?
J'ai eu 2 pb au niveau de Python 23 lui-même :
- Dès qu'un code-source contenait des caractères accentués,
j'avais un
"warning" (non-bloquant) ; ma solution précédente (au niveau de site),
ne fonctionnait plus, et j'ai mis plusieurs heures à trouver qu'il
fallait ajouter # -*- coding: cp1252 -*- au début de mon code.
- Plus gênant : j'utilise un serveur COM (en Python), pour ajouter
des
fonctionnalités à mes logiciels Windows. Les paramètres sont passés en
unicode. La récupération des paramètres dans Python ne marchait plus.
Il a fallut que refasse un encodage différent, dès réception des
paramètres.
Tout n'est d'ailleurs pas réglé, car, par exemple, un simple :
print "Aïe"
exécuté en invite de commande windows (console) n'affiche pas le "i
tréma" normalement. Il faut faire un truc du genre :
print "Aïe".decode('cp1252')
Ce qui est quand même un poil gênant. A noter que, dans windows
lui-même, il n'y a pas de problème.
Concernant les modules externes, difficile de s'en passer, tant il en
existe. C'est d'ailleurs une des forces de Python. Cependant, il
arrivait qu'un module prévu pour Python2.2 ne fonctionnait pas sous
Python2.3. Il fallait donc attendre la disponibilité du module dans
cette version.
Or, j'ai dû renoncer à quelques modules, qui n'étaient
plus suivis. Dès lors se pose la question du choix des modules (et
outils). Avec deux critères : la pérennité, et la réactivité.
Un exemple : Boa-constructor. Bel outil, impressionnant. Et pourtant,
il ne fonctionne pas avec la dernière version de wxPython, pourtant
sortie depuis plusieurs mois. Du coup, comme la visibilité est trop
réduite, j'ai laissé tomber.
Ceci dit, ce problème n'est pas propre à Python.
Ca m'embêterait de devoir recoder sans cesse une interface
graphique lorsque je passe à la version supérieure
Oui, je suis dans le même cas. Mais Python étant Python, j'ai aperçu
le moyen de définir des niveaux d'abstraction intermédiaires, qui
limiteront les modifications nécessaires à, seulement, quelques points
de passage. Il faut, aussi, que je regarde la surcouche wax (
http://wiki.wxpython.org/index.cgi/Wax )
en entreprise, on me regarde avec des gros yeux quand j'en
parle...
Là, il faut le prendre de haut. Que quelqu'un ne pratique pas, ou
n'utilise pas, Python, soit. Mais ne pas en avoir entendu parler
prouve une incompétence flagrante.
Cela montre que la personne n'est pas au courant des technologies de
l'informatique.
Le gros problème de Python, en entreprise, c'est qu'il est libre. La
foule des commerciaux qui assiège les directions ne parlent que de ce
qui se VEND, d'où une occultation des autres solutions.
Perso, j'ai la chance de pouvoir imposer mes choix, en ne proposant
que des solutions. Mais, au vu des possibilités que je leur offre, les
clients en(re)-connaissent vite l'intérêt.
Pourrais-tu rentrer un peu plus dans les détails ?
J'ai eu 2 pb au niveau de Python 23 lui-même :
- Dès qu'un code-source contenait des caractères accentués,
j'avais un
"warning" (non-bloquant) ; ma solution précédente (au niveau de site),
ne fonctionnait plus, et j'ai mis plusieurs heures à trouver qu'il
fallait ajouter # -*- coding: cp1252 -*- au début de mon code.
- Plus gênant : j'utilise un serveur COM (en Python), pour ajouter
des
fonctionnalités à mes logiciels Windows. Les paramètres sont passés en
unicode. La récupération des paramètres dans Python ne marchait plus.
Il a fallut que refasse un encodage différent, dès réception des
paramètres.
Tout n'est d'ailleurs pas réglé, car, par exemple, un simple :
print "Aïe"
exécuté en invite de commande windows (console) n'affiche pas le "i
tréma" normalement. Il faut faire un truc du genre :
print "Aïe".decode('cp1252')
Ce qui est quand même un poil gênant. A noter que, dans windows
lui-même, il n'y a pas de problème.
Concernant les modules externes, difficile de s'en passer, tant il en
existe. C'est d'ailleurs une des forces de Python. Cependant, il
arrivait qu'un module prévu pour Python2.2 ne fonctionnait pas sous
Python2.3. Il fallait donc attendre la disponibilité du module dans
cette version.
Or, j'ai dû renoncer à quelques modules, qui n'étaient
plus suivis. Dès lors se pose la question du choix des modules (et
outils). Avec deux critères : la pérennité, et la réactivité.
Un exemple : Boa-constructor. Bel outil, impressionnant. Et pourtant,
il ne fonctionne pas avec la dernière version de wxPython, pourtant
sortie depuis plusieurs mois. Du coup, comme la visibilité est trop
réduite, j'ai laissé tomber.
Ceci dit, ce problème n'est pas propre à Python.
Ca m'embêterait de devoir recoder sans cesse une interface
graphique lorsque je passe à la version supérieure
Oui, je suis dans le même cas. Mais Python étant Python, j'ai aperçu
le moyen de définir des niveaux d'abstraction intermédiaires, qui
limiteront les modifications nécessaires à, seulement, quelques points
de passage. Il faut, aussi, que je regarde la surcouche wax (
http://wiki.wxpython.org/index.cgi/Wax )
en entreprise, on me regarde avec des gros yeux quand j'en
parle...
Là, il faut le prendre de haut. Que quelqu'un ne pratique pas, ou
n'utilise pas, Python, soit. Mais ne pas en avoir entendu parler
prouve une incompétence flagrante.
Cela montre que la personne n'est pas au courant des technologies de
l'informatique.
Le gros problème de Python, en entreprise, c'est qu'il est libre. La
foule des commerciaux qui assiège les directions ne parlent que de ce
qui se VEND, d'où une occultation des autres solutions.
Perso, j'ai la chance de pouvoir imposer mes choix, en ne proposant
que des solutions. Mais, au vu des possibilités que je leur offre, les
clients en(re)-connaissent vite l'intérêt.
Ou alors, il a un mauvais prof (=> changer le prof ! )
Ou alors, il a un mauvais prof (=> changer le prof ! )
Ou alors, il a un mauvais prof (=> changer le prof ! )
Est-ce que l'on a une compatibilité ascendante parfaite ?
Pas parfaite, mais il ne tient qu'à toi de passer à la version
supérieure de python ou pas. Ceci dit, au niveau de python, le
langage, je n'ai jamais eu de soucis de compatibilité
ascendante.
Pourrais-tu me dire sur quel type de projets tu as travaillé ?
sites web, scripts d'admin unix et applis de gestion sous windows,
dont certaines utilisées en milieu industriel 24h/24.
Bon Ok ça devrait aller pour moi alors...
Tien par ex, pour une appli 24h/24, j'ai utilisé BaseHTTPServer, qui
n'est soit-disant pas prêt pour la production... Il a également été
utilisé par l'afnic pour l'ouverture des .fr !
http://pythonology.org/success&story=suzanne
Il semblerait que la compatibilité ascendante avec wxpython
n'est vraiment pas terrible (ce qui est normal pour un projet
jeune et dynamique). A quel point est-ce rébarbatif ?
wx n'est pas spécialement un projet jeune, il date de 1992 et
est très stable, tu peux foncer. Ensuite, concernant la
compatibilité ascendante, c'est encore à toi de voir, tu peux
suivre l'évolution de la librairie à ton rythme.
Personellement, dans la mesure du possible je privilégie les
interfaces web, c'est beaucoup plus polyvalent.
Oui cependant changer de version me paraît un processus
inéluctable : il y a toujours des bogues à corriger, des
fonctionnalités que l'on recherche, etc...
Cela m'embêterait assez de devoir tout reprendre à chaque fois...
Tout reprendre, non, loin de la... Les tests unitaires sont nos
amis pour le confirmer :-)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
Si tu utilise des tests unitaires, tu controle le comportement du
programme, je rentre X il doit me sortir Y. Et si ce n'est pas le cas,
suivant comment tu as codé tu aura des exceptions ou autres... C'est
pour ça que les GUI, moins on en fait mieux on dort ;-)
Si tas question est d'être prévenu par les développeurs, à chaque
release il y a toujours un fichier contenant une explication sur ce
qui a changé par rapport à la version précédente.
Est-ce que l'on a une compatibilité ascendante parfaite ?
Pas parfaite, mais il ne tient qu'à toi de passer à la version
supérieure de python ou pas. Ceci dit, au niveau de python, le
langage, je n'ai jamais eu de soucis de compatibilité
ascendante.
Pourrais-tu me dire sur quel type de projets tu as travaillé ?
sites web, scripts d'admin unix et applis de gestion sous windows,
dont certaines utilisées en milieu industriel 24h/24.
Bon Ok ça devrait aller pour moi alors...
Tien par ex, pour une appli 24h/24, j'ai utilisé BaseHTTPServer, qui
n'est soit-disant pas prêt pour la production... Il a également été
utilisé par l'afnic pour l'ouverture des .fr !
http://pythonology.org/success&story=suzanne
Il semblerait que la compatibilité ascendante avec wxpython
n'est vraiment pas terrible (ce qui est normal pour un projet
jeune et dynamique). A quel point est-ce rébarbatif ?
wx n'est pas spécialement un projet jeune, il date de 1992 et
est très stable, tu peux foncer. Ensuite, concernant la
compatibilité ascendante, c'est encore à toi de voir, tu peux
suivre l'évolution de la librairie à ton rythme.
Personellement, dans la mesure du possible je privilégie les
interfaces web, c'est beaucoup plus polyvalent.
Oui cependant changer de version me paraît un processus
inéluctable : il y a toujours des bogues à corriger, des
fonctionnalités que l'on recherche, etc...
Cela m'embêterait assez de devoir tout reprendre à chaque fois...
Tout reprendre, non, loin de la... Les tests unitaires sont nos
amis pour le confirmer :-)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
Si tu utilise des tests unitaires, tu controle le comportement du
programme, je rentre X il doit me sortir Y. Et si ce n'est pas le cas,
suivant comment tu as codé tu aura des exceptions ou autres... C'est
pour ça que les GUI, moins on en fait mieux on dort ;-)
Si tas question est d'être prévenu par les développeurs, à chaque
release il y a toujours un fichier contenant une explication sur ce
qui a changé par rapport à la version précédente.
Est-ce que l'on a une compatibilité ascendante parfaite ?
Pas parfaite, mais il ne tient qu'à toi de passer à la version
supérieure de python ou pas. Ceci dit, au niveau de python, le
langage, je n'ai jamais eu de soucis de compatibilité
ascendante.
Pourrais-tu me dire sur quel type de projets tu as travaillé ?
sites web, scripts d'admin unix et applis de gestion sous windows,
dont certaines utilisées en milieu industriel 24h/24.
Bon Ok ça devrait aller pour moi alors...
Tien par ex, pour une appli 24h/24, j'ai utilisé BaseHTTPServer, qui
n'est soit-disant pas prêt pour la production... Il a également été
utilisé par l'afnic pour l'ouverture des .fr !
http://pythonology.org/success&story=suzanne
Il semblerait que la compatibilité ascendante avec wxpython
n'est vraiment pas terrible (ce qui est normal pour un projet
jeune et dynamique). A quel point est-ce rébarbatif ?
wx n'est pas spécialement un projet jeune, il date de 1992 et
est très stable, tu peux foncer. Ensuite, concernant la
compatibilité ascendante, c'est encore à toi de voir, tu peux
suivre l'évolution de la librairie à ton rythme.
Personellement, dans la mesure du possible je privilégie les
interfaces web, c'est beaucoup plus polyvalent.
Oui cependant changer de version me paraît un processus
inéluctable : il y a toujours des bogues à corriger, des
fonctionnalités que l'on recherche, etc...
Cela m'embêterait assez de devoir tout reprendre à chaque fois...
Tout reprendre, non, loin de la... Les tests unitaires sont nos
amis pour le confirmer :-)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
Si tu utilise des tests unitaires, tu controle le comportement du
programme, je rentre X il doit me sortir Y. Et si ce n'est pas le cas,
suivant comment tu as codé tu aura des exceptions ou autres... C'est
pour ça que les GUI, moins on en fait mieux on dort ;-)
Si tas question est d'être prévenu par les développeurs, à chaque
release il y a toujours un fichier contenant une explication sur ce
qui a changé par rapport à la version précédente.
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
En ce qui concerne Python (langage...) , généralement, il y a des
warnings sur le code 'deprecated' assez longtemps à l'avance. Par
conséquent, dans bon nombre de cas, les modules tierces déclencheront
aussi ces warnings.
En tout cas je viens toute juste de faire ma première petite
application en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer
de la programmation il n'y a pas mieux...)
<troll>
Les décideurs ne sont généralement pas compétents techniquement, et
pour ne pas prendre de risque s'en tiennent aux solutions 'standard'
du moment (le 'standard' étant généralement défini par 'ce que les
autres utilisent, surtout s'il y a une grosse boite derrière qui
pousse'). Un chef de projet n'a jamais été viré pour avoir choisi
Java...
Bon nombre d'écoles cherchent avant tout à recaser leurs élèves, donc
leur enseigne les technos les plus demandées du moment (au lieu de
leur enseigner l'informatique en général...).
Il en résulte que la majorité des programmeurs à un instant T
maîtrisent essentiellement les techno 'standard' au moment de leur
entrée en formation. Et donc qu'il est plus facile de recruter des
programmeurs connaissant ces technos. Ce qui renforce la tendance des
décideurs à favoriser ces technos (les dits décideurs n'ayant toujours
pas compris qu'il vaut mieux avoir des programmeurs avec une bonne
culture et une bonne capacité d'adaptation que des pisseurs de code ne
connaissant qu'une paire de techno, et incapable d'en apprendre une
nouvelle par eux-même).
</troll>
Ceci étant, de plus en plus de boites passent en ce moment à
Zope/Python pour leur développement Web (à part bien sûr celles qui
ont un abonnement à vie chez MS...)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
En ce qui concerne Python (langage...) , généralement, il y a des
warnings sur le code 'deprecated' assez longtemps à l'avance. Par
conséquent, dans bon nombre de cas, les modules tierces déclencheront
aussi ces warnings.
En tout cas je viens toute juste de faire ma première petite
application en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer
de la programmation il n'y a pas mieux...)
<troll>
Les décideurs ne sont généralement pas compétents techniquement, et
pour ne pas prendre de risque s'en tiennent aux solutions 'standard'
du moment (le 'standard' étant généralement défini par 'ce que les
autres utilisent, surtout s'il y a une grosse boite derrière qui
pousse'). Un chef de projet n'a jamais été viré pour avoir choisi
Java...
Bon nombre d'écoles cherchent avant tout à recaser leurs élèves, donc
leur enseigne les technos les plus demandées du moment (au lieu de
leur enseigner l'informatique en général...).
Il en résulte que la majorité des programmeurs à un instant T
maîtrisent essentiellement les techno 'standard' au moment de leur
entrée en formation. Et donc qu'il est plus facile de recruter des
programmeurs connaissant ces technos. Ce qui renforce la tendance des
décideurs à favoriser ces technos (les dits décideurs n'ayant toujours
pas compris qu'il vaut mieux avoir des programmeurs avec une bonne
culture et une bonne capacité d'adaptation que des pisseurs de code ne
connaissant qu'une paire de techno, et incapable d'en apprendre une
nouvelle par eux-même).
</troll>
Ceci étant, de plus en plus de boites passent en ce moment à
Zope/Python pour leur développement Web (à part bien sûr celles qui
ont un abonnement à vie chez MS...)
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
En ce qui concerne Python (langage...) , généralement, il y a des
warnings sur le code 'deprecated' assez longtemps à l'avance. Par
conséquent, dans bon nombre de cas, les modules tierces déclencheront
aussi ces warnings.
En tout cas je viens toute juste de faire ma première petite
application en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer
de la programmation il n'y a pas mieux...)
<troll>
Les décideurs ne sont généralement pas compétents techniquement, et
pour ne pas prendre de risque s'en tiennent aux solutions 'standard'
du moment (le 'standard' étant généralement défini par 'ce que les
autres utilisent, surtout s'il y a une grosse boite derrière qui
pousse'). Un chef de projet n'a jamais été viré pour avoir choisi
Java...
Bon nombre d'écoles cherchent avant tout à recaser leurs élèves, donc
leur enseigne les technos les plus demandées du moment (au lieu de
leur enseigner l'informatique en général...).
Il en résulte que la majorité des programmeurs à un instant T
maîtrisent essentiellement les techno 'standard' au moment de leur
entrée en formation. Et donc qu'il est plus facile de recruter des
programmeurs connaissant ces technos. Ce qui renforce la tendance des
décideurs à favoriser ces technos (les dits décideurs n'ayant toujours
pas compris qu'il vaut mieux avoir des programmeurs avec une bonne
culture et une bonne capacité d'adaptation que des pisseurs de code ne
connaissant qu'une paire de techno, et incapable d'en apprendre une
nouvelle par eux-même).
</troll>
Ceci étant, de plus en plus de boites passent en ce moment à
Zope/Python pour leur développement Web (à part bien sûr celles qui
ont un abonnement à vie chez MS...)
Si tu utilise des tests unitaires, tu controle le comportement du
programme, je rentre X il doit me sortir Y. Et si ce n'est pas le cas,
suivant comment tu as codé tu aura des exceptions ou autres... C'est
pour ça que les GUI, moins on en fait mieux on dort ;-)
Ok mais pour moi ce n'est pas si facile que ça : je viens du monde de la
programmation en C donc je suis habitué à :
a) une pérennité du langage quasi-parfaite (bon Ok le langage n'a
presque pas évolué en 15 ans, mais les compilateurs si et ça reste
toujours parfaitement compatible).
b) des tas de bogues insidieux qui font que si tu rentres X, tu auras
bien Y mais avec 3 débordements mémoires et 4 opérations non standards
mais qui marchent impeccablement sur la machine de test (bien sûr tout
cela est invisible).
Difficile de se dire qu'avec le python tous ces problèmes seront
miraculeusement résolus !
Si tas question est d'être prévenu par les développeurs, à chaque
release il y a toujours un fichier contenant une explication sur ce
qui a changé par rapport à la version précédente.
Espérons que ce fichier ne soit pas trop volumineux (type fichier de
changement d'un noyau linux...)...
Si tu utilise des tests unitaires, tu controle le comportement du
programme, je rentre X il doit me sortir Y. Et si ce n'est pas le cas,
suivant comment tu as codé tu aura des exceptions ou autres... C'est
pour ça que les GUI, moins on en fait mieux on dort ;-)
Ok mais pour moi ce n'est pas si facile que ça : je viens du monde de la
programmation en C donc je suis habitué à :
a) une pérennité du langage quasi-parfaite (bon Ok le langage n'a
presque pas évolué en 15 ans, mais les compilateurs si et ça reste
toujours parfaitement compatible).
b) des tas de bogues insidieux qui font que si tu rentres X, tu auras
bien Y mais avec 3 débordements mémoires et 4 opérations non standards
mais qui marchent impeccablement sur la machine de test (bien sûr tout
cela est invisible).
Difficile de se dire qu'avec le python tous ces problèmes seront
miraculeusement résolus !
Si tas question est d'être prévenu par les développeurs, à chaque
release il y a toujours un fichier contenant une explication sur ce
qui a changé par rapport à la version précédente.
Espérons que ce fichier ne soit pas trop volumineux (type fichier de
changement d'un noyau linux...)...
Si tu utilise des tests unitaires, tu controle le comportement du
programme, je rentre X il doit me sortir Y. Et si ce n'est pas le cas,
suivant comment tu as codé tu aura des exceptions ou autres... C'est
pour ça que les GUI, moins on en fait mieux on dort ;-)
Ok mais pour moi ce n'est pas si facile que ça : je viens du monde de la
programmation en C donc je suis habitué à :
a) une pérennité du langage quasi-parfaite (bon Ok le langage n'a
presque pas évolué en 15 ans, mais les compilateurs si et ça reste
toujours parfaitement compatible).
b) des tas de bogues insidieux qui font que si tu rentres X, tu auras
bien Y mais avec 3 débordements mémoires et 4 opérations non standards
mais qui marchent impeccablement sur la machine de test (bien sûr tout
cela est invisible).
Difficile de se dire qu'avec le python tous ces problèmes seront
miraculeusement résolus !
Si tas question est d'être prévenu par les développeurs, à chaque
release il y a toujours un fichier contenant une explication sur ce
qui a changé par rapport à la version précédente.
Espérons que ce fichier ne soit pas trop volumineux (type fichier de
changement d'un noyau linux...)...
C'est plutôt là le problème : le prof !
Cependant on est presque tous novice la première année (sinon on ne
prendrait pas de cours !), comment se rendre compte que le prof est
incompétent ?
IMO, généralement, un prof incompétent se détecte facilement: pour cela,
On ne s'en rend compte que bien plus tard, donc pour changer le prof
c'est pas gagné ! (et cela ne nous sert plus à grand chose)
On peut toujours utiliser le temps disponible pour travailler par soi-même.
C'est plutôt là le problème : le prof !
Cependant on est presque tous novice la première année (sinon on ne
prendrait pas de cours !), comment se rendre compte que le prof est
incompétent ?
IMO, généralement, un prof incompétent se détecte facilement: pour cela,
On ne s'en rend compte que bien plus tard, donc pour changer le prof
c'est pas gagné ! (et cela ne nous sert plus à grand chose)
On peut toujours utiliser le temps disponible pour travailler par soi-même.
C'est plutôt là le problème : le prof !
Cependant on est presque tous novice la première année (sinon on ne
prendrait pas de cours !), comment se rendre compte que le prof est
incompétent ?
IMO, généralement, un prof incompétent se détecte facilement: pour cela,
On ne s'en rend compte que bien plus tard, donc pour changer le prof
c'est pas gagné ! (et cela ne nous sert plus à grand chose)
On peut toujours utiliser le temps disponible pour travailler par soi-même.
On Wed, 28 Jul 2004 19:24:40 +0200, Bruno DesthuilliersJustement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
En ce qui concerne Python (langage...) , généralement, il y a des
warnings sur le code 'deprecated' assez longtemps à l'avance. Par
conséquent, dans bon nombre de cas, les modules tierces déclencheront
aussi ces warnings.
Ah ! Excellent ! Ca c'est vraiment une bonne idée !En tout cas je viens toute juste de faire ma première petite
application en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer
de la programmation il n'y a pas mieux...)
<troll>
Les décideurs ne sont généralement pas compétents techniquement, et
pour ne pas prendre de risque s'en tiennent aux solutions 'standard'
du moment (le 'standard' étant généralement défini par 'ce que les
autres utilisent, surtout s'il y a une grosse boite derrière qui
pousse'). Un chef de projet n'a jamais été viré pour avoir choisi
Java...
Je ne sais pas, il doit bien y avoir autre chose quand même : les
décideurs d'aujourd'hui ne sont pas devenus décideurs du jour au
lendemain, ils ont bien été simples grouillots de base à une époque (je
parle des décideurs "accessibles" pas les big boss qui gouvernent la
planètes...).
Ou bien peut-être qu'on deviendra commme eux plus tard (Dien m'en
préserve !) ?Bon nombre d'écoles cherchent avant tout à recaser leurs élèves, donc
leur enseigne les technos les plus demandées du moment (au lieu de
leur enseigner l'informatique en général...).
Ca c'est comme ça que l'on nous a imposé le Java !Il en résulte que la majorité des programmeurs à un instant T
maîtrisent essentiellement les techno 'standard' au moment de leur
entrée en formation. Et donc qu'il est plus facile de recruter des
programmeurs connaissant ces technos. Ce qui renforce la tendance des
décideurs à favoriser ces technos (les dits décideurs n'ayant toujours
pas compris qu'il vaut mieux avoir des programmeurs avec une bonne
culture et une bonne capacité d'adaptation que des pisseurs de code ne
connaissant qu'une paire de techno, et incapable d'en apprendre une
nouvelle par eux-même).
Il y a plus sournois que ça : je me renseigne actuellement sur le python
car nous cherchons une alternative à matlab qui coûte vraiment très
cher. Et bien je m'aperçois que matlab a une politique de licence
presque gratuite pour les étudiants et les écoles. Résultat :
l'utilisation de matlab en entreprise est accentué car le personnel a la
flemme d'apprendre un autre langage (ça m'a pris deux jours pour digérer
les grands principes de python...) et utilise presque exclusivement
matlab...
Pareil pour microsoft (on dérive là...), licence presque gratuite pour
les étudiants qui lorsqu'on leur demandera leur avis en entreprise
"préfèreront avoir un poste Windows".
Plus cynique encore, on peut encourager le piratage "car vous
deviendrez dépendant et on trouvera bien un moyen de vous faire payer un
jour..." (la première dose est gratuite...).</troll>
Ceci étant, de plus en plus de boites passent en ce moment à
Zope/Python pour leur développement Web (à part bien sûr celles qui
ont un abonnement à vie chez MS...)
C'est notre cas : on vient de tout basculer sur XP (car le support de
NT ne sera plus assuré), ça nous a coûté une fortune et on vient de
choper le premier virus qui a mis tout le réseau à genoux pendant plus
d'un jour...
Plus je découvre Python et plus je m'aperçois qu'il gagne vraiment à
être plus utilisé. Au début je cherchais un moyen de réaliser une GUI de
manière simple, je tombe sur wxPython et je me documente donc sur Python
et ô stupeur c'est un langage très facile, ô stupeur il est néanmoins
très puissant, ô stupeur il peut remplacer les calculs de matlab
(numarray), ô stupeur on peut aussi tracer de beaux graphiques
(matplotlib)... et ça continue depuis...
On Wed, 28 Jul 2004 19:24:40 +0200, Bruno Desthuilliers
Justement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
En ce qui concerne Python (langage...) , généralement, il y a des
warnings sur le code 'deprecated' assez longtemps à l'avance. Par
conséquent, dans bon nombre de cas, les modules tierces déclencheront
aussi ces warnings.
Ah ! Excellent ! Ca c'est vraiment une bonne idée !
En tout cas je viens toute juste de faire ma première petite
application en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer
de la programmation il n'y a pas mieux...)
<troll>
Les décideurs ne sont généralement pas compétents techniquement, et
pour ne pas prendre de risque s'en tiennent aux solutions 'standard'
du moment (le 'standard' étant généralement défini par 'ce que les
autres utilisent, surtout s'il y a une grosse boite derrière qui
pousse'). Un chef de projet n'a jamais été viré pour avoir choisi
Java...
Je ne sais pas, il doit bien y avoir autre chose quand même : les
décideurs d'aujourd'hui ne sont pas devenus décideurs du jour au
lendemain, ils ont bien été simples grouillots de base à une époque (je
parle des décideurs "accessibles" pas les big boss qui gouvernent la
planètes...).
Ou bien peut-être qu'on deviendra commme eux plus tard (Dien m'en
préserve !) ?
Bon nombre d'écoles cherchent avant tout à recaser leurs élèves, donc
leur enseigne les technos les plus demandées du moment (au lieu de
leur enseigner l'informatique en général...).
Ca c'est comme ça que l'on nous a imposé le Java !
Il en résulte que la majorité des programmeurs à un instant T
maîtrisent essentiellement les techno 'standard' au moment de leur
entrée en formation. Et donc qu'il est plus facile de recruter des
programmeurs connaissant ces technos. Ce qui renforce la tendance des
décideurs à favoriser ces technos (les dits décideurs n'ayant toujours
pas compris qu'il vaut mieux avoir des programmeurs avec une bonne
culture et une bonne capacité d'adaptation que des pisseurs de code ne
connaissant qu'une paire de techno, et incapable d'en apprendre une
nouvelle par eux-même).
Il y a plus sournois que ça : je me renseigne actuellement sur le python
car nous cherchons une alternative à matlab qui coûte vraiment très
cher. Et bien je m'aperçois que matlab a une politique de licence
presque gratuite pour les étudiants et les écoles. Résultat :
l'utilisation de matlab en entreprise est accentué car le personnel a la
flemme d'apprendre un autre langage (ça m'a pris deux jours pour digérer
les grands principes de python...) et utilise presque exclusivement
matlab...
Pareil pour microsoft (on dérive là...), licence presque gratuite pour
les étudiants qui lorsqu'on leur demandera leur avis en entreprise
"préfèreront avoir un poste Windows".
Plus cynique encore, on peut encourager le piratage "car vous
deviendrez dépendant et on trouvera bien un moyen de vous faire payer un
jour..." (la première dose est gratuite...).
</troll>
Ceci étant, de plus en plus de boites passent en ce moment à
Zope/Python pour leur développement Web (à part bien sûr celles qui
ont un abonnement à vie chez MS...)
C'est notre cas : on vient de tout basculer sur XP (car le support de
NT ne sera plus assuré), ça nous a coûté une fortune et on vient de
choper le premier virus qui a mis tout le réseau à genoux pendant plus
d'un jour...
Plus je découvre Python et plus je m'aperçois qu'il gagne vraiment à
être plus utilisé. Au début je cherchais un moyen de réaliser une GUI de
manière simple, je tombe sur wxPython et je me documente donc sur Python
et ô stupeur c'est un langage très facile, ô stupeur il est néanmoins
très puissant, ô stupeur il peut remplacer les calculs de matlab
(numarray), ô stupeur on peut aussi tracer de beaux graphiques
(matplotlib)... et ça continue depuis...
On Wed, 28 Jul 2004 19:24:40 +0200, Bruno DesthuilliersJustement je posais la question à l'autre intervenant de ce fil :
Est-on prévenu par un moyen quelconque qu'il faut modifier le code
(erreur de syntaxe ?) ou bien le programme plante-t-il (exception ?)
ou se met à faire n'importe quoi (beaucoup plus difficile à
déboguer)
En ce qui concerne Python (langage...) , généralement, il y a des
warnings sur le code 'deprecated' assez longtemps à l'avance. Par
conséquent, dans bon nombre de cas, les modules tierces déclencheront
aussi ces warnings.
Ah ! Excellent ! Ca c'est vraiment une bonne idée !En tout cas je viens toute juste de faire ma première petite
application en python et je suis comment dire... bluffé !
Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école (parce que bon le Java et le C, Ok c'est
immédiatement utilisable en entreprise mais bon pour vous écoeurer
de la programmation il n'y a pas mieux...)
<troll>
Les décideurs ne sont généralement pas compétents techniquement, et
pour ne pas prendre de risque s'en tiennent aux solutions 'standard'
du moment (le 'standard' étant généralement défini par 'ce que les
autres utilisent, surtout s'il y a une grosse boite derrière qui
pousse'). Un chef de projet n'a jamais été viré pour avoir choisi
Java...
Je ne sais pas, il doit bien y avoir autre chose quand même : les
décideurs d'aujourd'hui ne sont pas devenus décideurs du jour au
lendemain, ils ont bien été simples grouillots de base à une époque (je
parle des décideurs "accessibles" pas les big boss qui gouvernent la
planètes...).
Ou bien peut-être qu'on deviendra commme eux plus tard (Dien m'en
préserve !) ?Bon nombre d'écoles cherchent avant tout à recaser leurs élèves, donc
leur enseigne les technos les plus demandées du moment (au lieu de
leur enseigner l'informatique en général...).
Ca c'est comme ça que l'on nous a imposé le Java !Il en résulte que la majorité des programmeurs à un instant T
maîtrisent essentiellement les techno 'standard' au moment de leur
entrée en formation. Et donc qu'il est plus facile de recruter des
programmeurs connaissant ces technos. Ce qui renforce la tendance des
décideurs à favoriser ces technos (les dits décideurs n'ayant toujours
pas compris qu'il vaut mieux avoir des programmeurs avec une bonne
culture et une bonne capacité d'adaptation que des pisseurs de code ne
connaissant qu'une paire de techno, et incapable d'en apprendre une
nouvelle par eux-même).
Il y a plus sournois que ça : je me renseigne actuellement sur le python
car nous cherchons une alternative à matlab qui coûte vraiment très
cher. Et bien je m'aperçois que matlab a une politique de licence
presque gratuite pour les étudiants et les écoles. Résultat :
l'utilisation de matlab en entreprise est accentué car le personnel a la
flemme d'apprendre un autre langage (ça m'a pris deux jours pour digérer
les grands principes de python...) et utilise presque exclusivement
matlab...
Pareil pour microsoft (on dérive là...), licence presque gratuite pour
les étudiants qui lorsqu'on leur demandera leur avis en entreprise
"préfèreront avoir un poste Windows".
Plus cynique encore, on peut encourager le piratage "car vous
deviendrez dépendant et on trouvera bien un moyen de vous faire payer un
jour..." (la première dose est gratuite...).</troll>
Ceci étant, de plus en plus de boites passent en ce moment à
Zope/Python pour leur développement Web (à part bien sûr celles qui
ont un abonnement à vie chez MS...)
C'est notre cas : on vient de tout basculer sur XP (car le support de
NT ne sera plus assuré), ça nous a coûté une fortune et on vient de
choper le premier virus qui a mis tout le réseau à genoux pendant plus
d'un jour...
Plus je découvre Python et plus je m'aperçois qu'il gagne vraiment à
être plus utilisé. Au début je cherchais un moyen de réaliser une GUI de
manière simple, je tombe sur wxPython et je me documente donc sur Python
et ô stupeur c'est un langage très facile, ô stupeur il est néanmoins
très puissant, ô stupeur il peut remplacer les calculs de matlab
(numarray), ô stupeur on peut aussi tracer de beaux graphiques
(matplotlib)... et ça continue depuis...
Christophe wrote:On Wed, 28 Jul 2004 19:24:40 +0200, Bruno Desthuilliers
[...]
Si tu a besoin d'arguments pour convaincre tes boss (en vrac, liste non
exhaustive):
[...]
Christophe wrote:
On Wed, 28 Jul 2004 19:24:40 +0200, Bruno Desthuilliers
[...]
Si tu a besoin d'arguments pour convaincre tes boss (en vrac, liste non
exhaustive):
[...]
Christophe wrote:On Wed, 28 Jul 2004 19:24:40 +0200, Bruno Desthuilliers
[...]
Si tu a besoin d'arguments pour convaincre tes boss (en vrac, liste non
exhaustive):
[...]
