Stabilité de python

Bonsoir !

Ce sont des avis personnels :
- je trouve Python très stable ; suffisamment pour du développement en
entreprise ;
- la compatibilité ascendante a été bonne, sans être parfaite (je n'ai
subit que 2.1=>2.2 et 2.2=>2.3). Le problème principal vient surtout de la
disponibilité de certains modules "tiers" (et un problème d'encodage des
sources, avec 2.3)
- je commence aussi à m'intéresser à wxPython. Je ne suis que sous
windows, et c'est un des rares GUI à pouvoir faire fonctionner les active-X.
Il est vrai qu'à chaque version, il y a des choses à re-écrire. Et,
surtout, toutes les docs sont en anglais (ce qui est péjoratif, pour moi).
Si ça continue, il va falloir faire quelques chose (à partir du présent NG
? )
- Python est un langage qui me plaît beaucoup, que je n'utilise que
minoritairement, professionnellement. Mais j'ai bien l'intention d'augmenter
son ratio (d'où le passage par wxPython).

@-salutations
--
Michel Claveau

Christophe <chris_invalid@yahoo.fr> writes:

Bonjour !

Avant de me lancer à corps perdu dans le python j'aurais quelques
questions concernant la stabilité de python.

J'aimerais savoir quel est la pérennité d'un programme codé en python ?

Très bonne, il n'y a qu'à voir le nombre encore très important
d'applications codées en python 1.5 (1999) qui fonctionnent toujours.

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.

Dans le cas contraire quel est en général le pourcentage du code à
recoder lors d'une transition vers une version supérieure et à quel
rythme cela arrive ?

Ca dépend fortement des modules externes que tu va utiliser. Si aucun,
il n'y aurra sûrement rien à changer, tu peux consulter les "what's new"
des précédentes versions pour avoir une idée.

D'autre part je m'intéresse de très près à wxpython qui me semble très
intéressant. Est-ce que vous jugez que cette technologie est prête pour
une utilisation en entreprise ou bien me conseillez vous a) d'attendre
un peu ou b) me tourner vers une autre solution de développement de GUI
?

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.

--
Wilk - http://flibuste.net

On Tue, 27 Jul 2004 00:14:34 +0200, "Michel Claveau, résurectionné
d'outre-bombe informatique"

Ce sont des avis personnels :
- je trouve Python très stable ; suffisamment pour du
développement en entreprise ;
- la compatibilité ascendante a été bonne, sans être parfaite (je
n'ai subit que 2.1=>2.2 et 2.2=>2.3). Le problème principal
vient surtout de la disponibilité de certains modules "tiers" (et
un problème d'encodage des sources, avec 2.3)

Pourrais-tu rentrer un peu plus dans les détails ?
Qu'est-ce qui a posé problème exactement ?
Est-ce que c'était des projets classiques ou bien faisais-tu appel à
nombre de fonctions ésotériques ?
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)

- je commence aussi à m'intéresser à wxPython. Je ne suis que sous
windows, et c'est un des rares GUI à pouvoir faire fonctionner les
active-X. Il est vrai qu'à chaque version, il y a des choses à
re-écrire. Et, surtout, toutes les docs sont en anglais (ce qui est
péjoratif, pour moi). Si ça continue, il va falloir faire quelques
chose (à partir du présent NG? )

Ah effectivement cela me refroidit un peu...
Ca m'embêterait de devoir recoder sans cesse une interface graphique
lorsque je passe à la version supérieure (pour des corrections de bogues
ou pour avoir des fonctionnalités en plus)

- Python est un langage qui me plaît beaucoup, que je n'utilise
que minoritairement, professionnellement. Mais j'ai bien
l'intention
d'augmenter son ratio (d'où le passage par wxPython).

Moi aussi ce langage m'attire beaucoup mais pas facile de l'introduire
en entreprise, on me regarde avec des gros yeux quand j'en parle...

Merci pour ce retour d'expérience !

Christophe <chris_invalid@yahoo.fr> writes:

Bonjour !

Avant de me lancer à corps perdu dans le python j'aurais quelques
questions concernant la stabilité de python.

J'aimerais savoir quel est la pérennité d'un programme codé en
python ?

Très bonne, il n'y a qu'à voir le nombre encore très important
d'applications codées en python 1.5 (1999) qui fonctionnent toujours.

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é ?
Cela m'étonne assez que l'on ait aucun problème de compatibilité...


Cependant il est parfois inévitable de passer à la version supérieure
d'un langage (correction de bogues ou recherche d'une nouvelle
fonctionnalité) et dans ce cas pas facile de faire cohabiter deux
versions différentes de python (mais pas impossible j'ai en ce moment
deux versions de python sur ma Debian !).

Dans le cas contraire quel est en général le pourcentage du code à
recoder lors d'une transition vers une version supérieure et à quel
rythme cela arrive ?

Ca dépend fortement des modules externes que tu va utiliser. Si aucun,
il n'y aurra sûrement rien à changer, tu peux consulter les "what's
new" des précédentes versions pour avoir une idée.

Ah ! le problème vient donc des modules externes !
Cependant si ces modules sont eux-mêmes codés en python il ne devrait
pas y avoir de problèmes alors ?

D'autre part je m'intéresse de très près à wxpython qui me semble
très intéressant. Est-ce que vous jugez que cette technologie est
prête pour une utilisation en entreprise ou bien me conseillez vous
a) d'attendre un peu ou b) me tourner vers une autre solution de
développement de GUI?

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...

Merci pour tes infos !

Christophe <chris_invalid@yahoo.fr> writes:

Christophe <chris_invalid@yahoo.fr> writes:

Bonjour !

Avant de me lancer à corps perdu dans le python j'aurais quelques
questions concernant la stabilité de python.

J'aimerais savoir quel est la pérennité d'un programme codé en
python ?

Très bonne, il n'y a qu'à voir le nombre encore très important
d'applications codées en python 1.5 (1999) qui fonctionnent toujours.

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.

Cela m'étonne assez que l'on ait aucun problème de compatibilité...

Par rapport aux outils propriétaires que j'ai utilisé, c'est le jour et
la nuit à ce niveau.

Cependant il est parfois inévitable de passer à la version supérieure
d'un langage (correction de bogues ou recherche d'une nouvelle
fonctionnalité) et dans ce cas pas facile de faire cohabiter deux
versions différentes de python (mais pas impossible j'ai en ce moment
deux versions de python sur ma Debian !).

Ca ne pose aucun problème de faire fonctionner plusieurs versions de
python... Je ne suis jamais tombé sur des bugs m'obligeant à changer de
version non plus.

Dans le cas contraire quel est en général le pourcentage du code à
recoder lors d'une transition vers une version supérieure et à quel
rythme cela arrive ?

Ca dépend fortement des modules externes que tu va utiliser. Si aucun,
il n'y aurra sûrement rien à changer, tu peux consulter les "what's
new" des précédentes versions pour avoir une idée.

Ah ! le problème vient donc des modules externes !
Cependant si ces modules sont eux-mêmes codés en python il ne devrait
pas y avoir de problèmes alors ?

Il n'y a pas forcément de problèmes avec les modules externes, qu'ils
soient codés en python ou non, la seule contrainte est qu'il faut les
suivre à part, et là, chaque module est spécifique bien sûr (je ne parle
pas des modules standards).

D'autre part je m'intéresse de très près à wxpython qui me semble
très intéressant. Est-ce que vous jugez que cette technologie est
prête pour une utilisation en entreprise ou bien me conseillez vous
a) d'attendre un peu ou b) me tourner vers une autre solution de
développement de GUI?

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 :-)

--
Wilk - http://flibuste.net

Christophe <chris_invalid@yahoo.fr> writes:

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...

Cela m'étonne assez que l'on ait aucun problème de compatibilité...

Par rapport aux outils propriétaires que j'ai utilisé, c'est le jour
et la nuit à ce niveau.

Ah ! Ca me rassure !

Cependant il est parfois inévitable de passer à la version
supérieure d'un langage (correction de bogues ou recherche d'une
nouvelle fonctionnalité) et dans ce cas pas facile de faire
cohabiter deux versions différentes de python (mais pas impossible
j'ai en ce moment deux versions de python sur ma Debian !).

Ca ne pose aucun problème de faire fonctionner plusieurs versions de
python... Je ne suis jamais tombé sur des bugs m'obligeant à changer
de version non plus.

Très rassurant tout ça...

D'autre part je m'intéresse de très près à wxpython qui me semble
très intéressant. Est-ce que vous jugez que cette technologie est
prête pour une utilisation en entreprise ou bien me conseillez
vous a) d'attendre un peu ou b) me tourner vers une autre
solution dedéveloppement de GUI?

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)

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...)

Bonjour !

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.



Bonne journée.






Bonne journée.

Christophe wrote:

Je me demande vraiment pourquoi ce n'est pas ce genre de langage que
l'on nous apprend à l'école

bof. Je suis prof à Paris 12, et ca fait quelque temps que j'enseigne
python.

Mauvaise école --> changer d'école ;-)

Christophe <chris_invalid@yahoo.fr> writes:

Christophe <chris_invalid@yahoo.fr> writes:

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

[...]

D'autre part je m'intéresse de très près à wxpython qui me semble
très intéressant. Est-ce que vous jugez que cette technologie est
prête pour une utilisation en entreprise ou bien me conseillez
vous a) d'attendre un peu ou b) me tourner vers une autre
solution dedéveloppement de GUI?

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.

--
Wilk - http://flibuste.net

Ou alors, il a un mauvais prof (=> changer le prof ! )