vml a écrit :
> Bonsoir,
>
>
> J'essaye de promouvoir python dans ma societe. Notre utilisation
> serait un acces a OLE automation et du calcul scientifique avec scipy.
> Est-ce que python 3.0 va changer quelque chose a tout cela?
> -mes prog developpes en 2.x ne seront plus compatible avec 3.0

Ils seront toujours compatibles avec la version avec laquelle ils ont
été développés, laquelle n'est pas prête de disparaitre (pour info, il y
a encore des gens qui utilisent la 1.5.2, qui date de 1999).

Ceci étant, je doute que les problèmes de compatibilité soient si
important que ça - rien de comparable avec ce qu'on peut expérimenter
avec des technos propriétaires sous Windows en tous cas.

> -tous les modules developpes comme scipy et pywin32 ne seront pas
> disponibles pour python 3.0 ...

Pourquoi donc ?

> enfin j'imagine

Je pense en effet que c'est imaginaire.

>
> comment justifier cela face a des personnes qui ne voit que par
> microsoft et matlab ?

Justifier quoi ? Qu'une techno évolue ? Attention, les développeurs de
Python ont toujours été *très* attentifs à la compatibilité ascendante,
donc le fait que la 3.0 soit annoncée comme "non-compatible" n'implique
rien de comparable à ce qui est la norme dans les outils propriétaires
lors d'une version majeure.

vml a écrit :
> On 2 août, 15:55, Bruno Desthuilliers
> <bdesth.quelquech...@free.quelquepart.fr> wrote:
>
>>vml a écrit :
>>
>>
>>>Bonsoir,
>>
>>>J'essaye de promouvoir python dans ma societe. Notre utilisation
>>>serait un acces a OLE automation et du calcul scientifique avec scipy.
>>>Est-ce que python 3.0 va changer quelque chose a tout cela?
>>> -mes prog developpes en 2.x ne seront plus compatible avec 3.0
>>
>>Ils seront toujours compatibles avec la version avec laquelle ils ont
>>été développés, laquelle n'est pas prête de disparaitre (pour info, il y
>>a encore des gens qui utilisent la 1.5.2, qui date de 1999).
>>
>>Ceci étant, je doute que les problèmes de compatibilité soient si
>>important que ça - rien de comparable avec ce qu'on peut expérimenter
>>avec des technos propriétaires sous Windows en tous cas.
>>
>>
>>> -tous les modules developpes comme scipy et pywin32 ne seront pas
>>>disponibles pour python 3.0 ...
>>
>>Pourquoi donc ?
>>
>>
>>>enfin j'imagine
>>
>>Je pense en effet que c'est imaginaire.
>>
>>
>>
>>
>>>comment justifier cela face a des personnes qui ne voit que par
>>>microsoft et matlab ?
>>
>>Justifier quoi ? Qu'une techno évolue ? Attention, les développeurs de
>>Python ont toujours été *très* attentifs à la compatibilité ascendante,
>>donc le fait que la 3.0 soit annoncée comme "non-compatible" n'implique
>>rien de comparable à ce qui est la norme dans les outils propriétaires
>>lors d'une version majeure.
>
>
> merci pour vos reponses,
>
> en fait nous developpons en ce moment en vb 6 mais il y a un moment ou
> il va falloir faire autre chose (.net mais personne parmis mes
> collegue ne comprends l'objet et meme .net)

Heu... C'est marrant, je pensais entre autres aux problèmes de
compatibilité entre les différentes versions de VB !-)

Accessoirement, vb6 n'était déjà pas une nouveauté en 1999, quand j'ai
débuté avec Python 1.5.2. Depuis, on a vu plus d'évolutions dans Python
que dans vb, avec moins de problèmes de compatibilité. Et pour ce que
j'ai pu voir, il devrait y avoir moins de différences entre Python 2.6
et Python 3.0 qu'entre vb6 et vb7 (alias vb.NET).

> et python est simple
> facile a maintenir et surtout a matplotlib et scipy et bien d'autre
> chose qu'il n'y a pas avec vb .net ou c# est-je raison ?

Je ne connais pas assez vb.NET ou C# pour te le confirmer, mais le fait
est que depuis que je suis passé à Python, je n'ai pas trouvé de raison
(autres que soit la curiosité - et je suis très curieux - soit un choix
imposé de l'extérieur, j'entends) d'aller voir ailleurs.

> j'ai fait des script python pour les convaincre mais si je leur dis
> qu'il va peut etre falloir les changer ils vont me faire une crise ...

Je doute qu'il y ait beaucoup de changements à apporter.

> et je voudrais ecrire un module qui utilise les com layer de noter
> application pour le rendre encore plus accessible aux non programmeurs
> et python.... faire comme l'interface de matlab par exemple ....
>
> des ideespour convaincre les personnes ?

Ma main à couper que tu aura moins de boulot à porter tes dev Python
vers la 3.0 qu'à porter les appli VB6 vers .NET.

Sinon, accessoirement:
http://www.codeplex.com/Wiki/View.as...ame=IronPython
http://msdn.microsoft.com/msdnmag/is...lt.aspx?loc=fr

bref, MS lui-même supporte Python...

Bonsoir,


J'essaye de promouvoir python dans ma societe. Notre utilisation
serait un acces a OLE automation et du calcul scientifique avec scipy.
Est-ce que python 3.0 va changer quelque chose a tout cela?
-mes prog developpes en 2.x ne seront plus compatible avec 3.0
-tous les modules developpes comme scipy et pywin32 ne seront pas
disponibles pour python 3.0 ... enfin j'imagine


comment justifier cela face a des personnes qui ne voit que par
microsoft et matlab ?

Merci d'avance

On 02-08-2007, vml wrote:
> Bonsoir,
>
>
> J'essaye de promouvoir python dans ma societe. Notre utilisation
> serait un acces a OLE automation et du calcul scientifique avec scipy.
> Est-ce que python 3.0 va changer quelque chose a tout cela?
> -mes prog developpes en 2.x ne seront plus compatible avec 3.0

La plupart si, avec très peu de modifications.

> -tous les modules developpes comme scipy et pywin32 ne seront pas
> disponibles pour python 3.0 ... enfin j'imagine

Ce seront sûrement les premiers à être disponibles pour python 3.0 (si
c'est pas déjà le cas en partie), et en attendant rien n'empêche de
rester sur une 2.x qui sera supportée encore longtemps, tant qu'il
y aura des utilisateurs motivés.

>
>
> comment justifier cela face a des personnes qui ne voit que par
> microsoft et matlab ?

La compatibilité ascendante entre les différentes versions de python
a toujours été très bonne. Au pire des cas, la lisibilité du langage
permetra d'effectuer les modifications très facilement.

Pour ceux qui ne voient que par microsoft, et bien il suffit de les
rassurer en leur montrant que ironpython, version .net de python est
officiellement supportée par microsoft.

Pour ma part, j'ai aussi bien des clients sous linux que sous windows,
je ne me fait aucun soucis.

--
William Dodé - http://flibuste.net
Développeur informatique indépendant

On 2 août, 15:55, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr> wrote:
> vml a écrit :
>
> > Bonsoir,
>
> > J'essaye de promouvoir python dans ma societe. Notre utilisation
> > serait un acces a OLE automation et du calcul scientifique avec scipy.
> > Est-ce que python 3.0 va changer quelque chose a tout cela?
> > -mes prog developpes en 2.x ne seront plus compatible avec 3.0
>
> Ils seront toujours compatibles avec la version avec laquelle ils ont
> été développés, laquelle n'est pas prête de disparaitre (pour info, il y
> a encore des gens qui utilisent la 1.5.2, qui date de 1999).
>
> Ceci étant, je doute que les problèmes de compatibilité soient si
> important que ça - rien de comparable avec ce qu'on peut expérimenter
> avec des technos propriétaires sous Windows en tous cas.
>
> > -tous les modules developpes comme scipy et pywin32 ne seront pas
> > disponibles pour python 3.0 ...
>
> Pourquoi donc ?
>
> > enfin j'imagine
>
> Je pense en effet que c'est imaginaire.
>
>
>
> > comment justifier cela face a des personnes qui ne voit que par
> > microsoft et matlab ?
>
> Justifier quoi ? Qu'une techno évolue ? Attention, les développeurs de
> Python ont toujours été *très* attentifs à la compatibilité ascendante,
> donc le fait que la 3.0 soit annoncée comme "non-compatible" n'implique
> rien de comparable à ce qui est la norme dans les outils propriétaires
> lors d'une version majeure.

merci pour vos reponses,

en fait nous developpons en ce moment en vb 6 mais il y a un moment ou
il va falloir faire autre chose (.net mais personne parmis mes
collegue ne comprends l'objet et meme .net) et python est simple
facile a maintenir et surtout a matplotlib et scipy et bien d'autre
chose qu'il n'y a pas avec vb .net ou c# est-je raison ?

j'ai fait des script python pour les convaincre mais si je leur dis
qu'il va peut etre falloir les changer ils vont me faire une crise ...
et je voudrais ecrire un module qui utilise les com layer de noter
application pour le rendre encore plus accessible aux non programmeurs
et python.... faire comme l'interface de matlab par exemple ....


des ideespour convaincre les personnes ?

Bonsoir !

J'espère bien que PyWin32 fonctionnera sous Python 3.0 ; vu que je me sers de ce couple à longueur de journées.

Sinon, en complément de ce qu'à dit Bruno Desthuilliers, je rappelle que VB.Net n'est pas compatible du tout avec VB-6 (il y avait
même eu fronde et pétition, pour protester contre l'abandon de VB ; à ce début de révolte, MS n'a répondu que par un
"edit-and-continue" très partiel et approximatif)
..
Comme lui, je pense qu'il sera plus facile de passer à Python, que d'apprendre VB.Net.


Par contre, côté compatibilité ascendante, je suis moins optimiste que William, car, à chaque nouvelle version de Python, j'ai eu
plusieurs (petits) problèmes.
Cependant, je rejoins son avis : la compatibilité ascendante est quand même nettement supérieure à celle des logiciels MS.


Autre argument : tous les grands (commercialement) langages/outils de développement de MS sont beaucoup trop statiques. Ils
produisent bien quelques langages intéressants, comme IronPython ou F# (ou encore le shell powershell), mais de façon
confidentielle.
Et, quand on a goûté, avec Python, aux langages dynamiques, on a l'impression d'avoir re-trouvé un paradis perdu.

Et puis, un truc amusant : quand on lit les nouveautés des versions futures de C# (qui est quand même LE langage vedette de MS), on
se dit que, relativement à Python, soit ces "nouveautés" existent déjà dans Python, soit elles ne servent qu'à gommer
(partiellement), des faiblesses, par rapport à Python. Dans ces moments là, on se dit que Python a de l'avance, sur bien des
concepts.


Enfin, un conseil : ne pas chercher à traduire en Python des logiciels VB, car alors, on risque de passer à côté de beaucoup de
choses.
Il vaut mieux ré-écrire ces logiciels en Python, à partir d'un simple cahier des besoins.

@-salutations

Michel Claveau