je suis amené à travailler en environnement windows sur un projet
PowerBuilder pour rénover une application et pour essayer d'en améliorer
les performances assez médiocres. C'est une appli qui (jusqu'à présent)
lit des fichiers texte pour les injecter dans une base de données,
effectuer des calculs et ressortir des fichiers texte.
Là où ça devient très intéressant pour moi et en charte pour vous c'est
qu'à ma grande surprise la hiérarchie comme le collègue avec qui je
travaille ne sont pas contre le déport d'une partie des traitements vers
autre chose à définir mais qui pourrait être python si les tests sont
concluants[¹].
J'envisage dans un premier temps d'intégrer la sous-traitance vers
python de la manière la plus intégrée possible au système (par la suite
on pourrait envisager de déporter sur une machine dédiée sous linux) et
COM me semblait un bon candidat.
J'ai déjà fait quelques tests en ce sens avec les exemples fournis dans
win32com de python24, j'arrive à enregistrer une classe pour le système
et à l'instancier dans vba et dans PB.
Je profite que l'un des contributeurs du groupe est justement
spécialiste des serveurs com en python pour demander quelques conseils :
y a-t-il des pièges à éviter avec python+com ou des recettes à
appliquer ?
Par ailleurs, la classe inscrite dans le registre n'est pas visible dans
les browsers com, et lorsque l'objet est instancié, ses méthodes et
propriétés ne sont pas visibles. Je suppose qu'il manque des méthodes
aux exemples pour pouvoir rendre visible l'interface de la classe ?
[¹] et pour ce que j'ai déjà testé, j'obtiens par exemple des gains d'un
facteur 1500 sur une insertion dans une table Sybase par ODBC. PB permet
du RAD en bdd mais n'est visiblement pas très performant.
--
Sébastien Kirche
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Méta-MCI
Bonsoir !
Je profite que l'un des contributeurs du groupe est justement spécialiste des serveurs com en python
J'aimerais bien le rencontrer : ça pourrait être intéressant.
Sinon, quelques infos en vrac :
- il est normal qu'un serveur COM en Python ne soit pas visible dans les browser COM, car il n'y a pas de TLB (Type LiBrary) créé ou générée. Ce qui peut sembler un inconvénient peut devenir un avantage, car, avec Python, on peut créer des serveurs COM dynamiques. Par exemple, on peut définir de nouvelles fonctions pendant l'utilisation (chose impossible avec les serveurs statiques, pré-définis dans une TLB). On peut même aller plus loin, en définissant des fonctions visibles de l'extérieur, qui ne sont même pas déclarées dans Python, comme méthodes de la classe COM. Seulement, c'est un peu plus lent ; mais ça permet d'utiliser toutes les fonctions de la librairie standard, comme des fonctions directement utilisables de l'extérieur.
- parmi les pièges dont je me souviens : les passages de paramètres COM se font en unicode "interne". Autrement dit, c'est décodé par windows au départ de l'appel COM, et ré-encodé à la sortie.
- selon les langages utilisés, la casse peut être respectée ou non. Il est donc préférable de n'utiliser que des minuscules (ou que des majuscules).
- lors d'un appel de fonction, on peut très bien passer un nombre variable de paramètres, récupérés par une liste ( *param) ; ça marche bien. mais, impossible des passer des paramètres nommés
- avec certains langages, comme JScript, on peut aller plus loin, on "connectant" des "objets-COM-callback" sur des objets JScript. On peut ensuite appeler, par callback, des méthodes des objets JScript, ou lire écrire les propriétés, comme s'il s'agissait de propriétés du script Python. Je sais aussi faire ça avec Ruby, Perl, et VBscript, mais uniquement pour des sous-programmes appelés par Python.
- les serveurs COM ont une instance à chaque logiciel langage qui l'ouvre. Ce n'est pas comme avec Word, ou on peut avoir plusieurs logiciels connectés sur le même serveur COM. Néanmoins, si c'est indispensable, j'ai trouvé un moyen d'avoir un serveur COM commun et persistant. Mais c'est un peu tordu : il s'agit d'un pont en HTA (HTml-Application), qui instancie un Internet-Explorer invisible, et lui injecte une référence sur l'objet JScript "pont". On a donc un double-pont persistant. Mais, la contrepartie de cette persistance et de ce partage, c'est la vitesse : 5 fois plus lent que des appels directs.
- les threads fonctionnent bien ; et cela permet d'obtenir des performances apparentes fabuleuses : par exemple : l'utilisateur récupère la main immédiatement, pendant des threads travaillent sur un fichier en PDF, et l'envoi par e-mail (en tâche de fond).
- attention aux problèmes liés aux paramètres de sécurité trop stricts. Il y a encore des gens qui laisse en route le pare-feu standard de windows, alors, qu'ils ont un routeur-parefeu centralisé.
- autre piège : les chaînes de caractères des applications "utilisantes" sont souvent à zéro terminal ; cela peut poser des problèmes, surtout en retour.
- dans certains cas (Paradox+ObjectPAL), c'est réussi à faire fonctionner une DLL d'échange direct de blocs d'octets, entre des variables chaînes, binaires ou graphiques, et des strings Python, grâce à cTypes.
- Python étant aussi un excellent client COM, on peut utiliser un serveur-COM en Python, comme pont d'accès à d'autres logiciels/applications. Cela permet, par exemple, de piloter Word, Excel, Internet-Explorer, OpenOffice.org, etc, depuis des applications qui n'y arriveraient pas autrement.
- On arrive même, grâce à la structure géniale de Python, à faire du debugging ; mais ce n'est pas très simple.
- Mon serveur-COM en Python s'appelle Ponx. J'ai commencé un site dessus : http://ponx.org vous pourriez peut-être l'utiliser. L'avantage, c'est qu'il existe, qu'il tourne depuis plusieurs années, qu'il est extensible avec vos propres modules (comme tout script Python), qu'il existe aussi sous forme de CD auto-installable, qu'il y a une installation en ligne, ainsi que des programmes de mise à jour en ligne. Le problème, c'est la documentation, non terminée, et les exemples, très ciblée Paradox. Il y a aussi un newsgroup (adresse sur le site), pas très animé.
Sur ce, et bien que j'ai oublié plein d'éléments, que je ne vais pas me relire avant de rentrer me coucher, je vous souhaite une bonne nuit.
@-salutations -- Michel Claveau mél : http://cerbermail.com/?6J1TthIa8B
PS : si vous m'envoyez un e-mail, mettez un mot anti-filtre-spam dans l'objet. Par exemple : Python ou Ponx
Bonsoir !
Je profite que l'un des contributeurs du groupe est justement
spécialiste des serveurs com en python
J'aimerais bien le rencontrer : ça pourrait être intéressant.
Sinon, quelques infos en vrac :
- il est normal qu'un serveur COM en Python ne soit pas visible dans les
browser COM, car il n'y a pas de TLB (Type LiBrary) créé ou générée. Ce qui
peut sembler un inconvénient peut devenir un avantage, car, avec Python, on
peut créer des serveurs COM dynamiques. Par exemple, on peut définir de
nouvelles fonctions pendant l'utilisation (chose impossible avec les
serveurs statiques, pré-définis dans une TLB). On peut même aller plus loin,
en définissant des fonctions visibles de l'extérieur, qui ne sont même pas
déclarées dans Python, comme méthodes de la classe COM. Seulement, c'est un
peu plus lent ; mais ça permet d'utiliser toutes les fonctions de la
librairie standard, comme des fonctions directement utilisables de
l'extérieur.
- parmi les pièges dont je me souviens : les passages de paramètres COM se
font en unicode "interne". Autrement dit, c'est décodé par windows au départ
de l'appel COM, et ré-encodé à la sortie.
- selon les langages utilisés, la casse peut être respectée ou non. Il est
donc préférable de n'utiliser que des minuscules (ou que des majuscules).
- lors d'un appel de fonction, on peut très bien passer un nombre variable
de paramètres, récupérés par une liste ( *param) ; ça marche bien. mais,
impossible des passer des paramètres nommés
- avec certains langages, comme JScript, on peut aller plus loin, on
"connectant" des "objets-COM-callback" sur des objets JScript. On peut
ensuite appeler, par callback, des méthodes des objets JScript, ou lire
écrire les propriétés, comme s'il s'agissait de propriétés du script Python.
Je sais aussi faire ça avec Ruby, Perl, et VBscript, mais uniquement pour
des sous-programmes appelés par Python.
- les serveurs COM ont une instance à chaque logiciel langage qui l'ouvre.
Ce n'est pas comme avec Word, ou on peut avoir plusieurs logiciels
connectés sur le même serveur COM. Néanmoins, si c'est indispensable, j'ai
trouvé un moyen d'avoir un serveur COM commun et persistant. Mais c'est un
peu tordu : il s'agit d'un pont en HTA (HTml-Application), qui instancie un
Internet-Explorer invisible, et lui injecte une référence sur l'objet
JScript "pont". On a donc un double-pont persistant. Mais, la contrepartie
de cette persistance et de ce partage, c'est la vitesse : 5 fois plus lent
que des appels directs.
- les threads fonctionnent bien ; et cela permet d'obtenir des
performances apparentes fabuleuses : par exemple : l'utilisateur récupère la
main immédiatement, pendant des threads travaillent sur un fichier en PDF,
et l'envoi par e-mail (en tâche de fond).
- attention aux problèmes liés aux paramètres de sécurité trop stricts. Il
y a encore des gens qui laisse en route le pare-feu standard de windows,
alors, qu'ils ont un routeur-parefeu centralisé.
- autre piège : les chaînes de caractères des applications "utilisantes"
sont souvent à zéro terminal ; cela peut poser des problèmes, surtout en
retour.
- dans certains cas (Paradox+ObjectPAL), c'est réussi à faire fonctionner
une DLL d'échange direct de blocs d'octets, entre des variables chaînes,
binaires ou graphiques, et des strings Python, grâce à cTypes.
- Python étant aussi un excellent client COM, on peut utiliser un
serveur-COM en Python, comme pont d'accès à d'autres logiciels/applications.
Cela permet, par exemple, de piloter Word, Excel, Internet-Explorer,
OpenOffice.org, etc, depuis des applications qui n'y arriveraient pas
autrement.
- On arrive même, grâce à la structure géniale de Python, à faire du
debugging ; mais ce n'est pas très simple.
- Mon serveur-COM en Python s'appelle Ponx. J'ai commencé un site dessus
: http://ponx.org vous pourriez peut-être l'utiliser. L'avantage, c'est
qu'il existe, qu'il tourne depuis plusieurs années, qu'il est extensible
avec vos propres modules (comme tout script Python), qu'il existe aussi sous
forme de CD auto-installable, qu'il y a une installation en ligne, ainsi que
des programmes de mise à jour en ligne.
Le problème, c'est la documentation, non terminée, et les exemples, très
ciblée Paradox.
Il y a aussi un newsgroup (adresse sur le site), pas très animé.
Sur ce, et bien que j'ai oublié plein d'éléments, que je ne vais pas me
relire avant de rentrer me coucher, je vous souhaite une bonne nuit.
@-salutations
--
Michel Claveau
mél : http://cerbermail.com/?6J1TthIa8B
PS : si vous m'envoyez un e-mail, mettez un mot anti-filtre-spam dans
l'objet. Par exemple : Python ou Ponx
Je profite que l'un des contributeurs du groupe est justement spécialiste des serveurs com en python
J'aimerais bien le rencontrer : ça pourrait être intéressant.
Sinon, quelques infos en vrac :
- il est normal qu'un serveur COM en Python ne soit pas visible dans les browser COM, car il n'y a pas de TLB (Type LiBrary) créé ou générée. Ce qui peut sembler un inconvénient peut devenir un avantage, car, avec Python, on peut créer des serveurs COM dynamiques. Par exemple, on peut définir de nouvelles fonctions pendant l'utilisation (chose impossible avec les serveurs statiques, pré-définis dans une TLB). On peut même aller plus loin, en définissant des fonctions visibles de l'extérieur, qui ne sont même pas déclarées dans Python, comme méthodes de la classe COM. Seulement, c'est un peu plus lent ; mais ça permet d'utiliser toutes les fonctions de la librairie standard, comme des fonctions directement utilisables de l'extérieur.
- parmi les pièges dont je me souviens : les passages de paramètres COM se font en unicode "interne". Autrement dit, c'est décodé par windows au départ de l'appel COM, et ré-encodé à la sortie.
- selon les langages utilisés, la casse peut être respectée ou non. Il est donc préférable de n'utiliser que des minuscules (ou que des majuscules).
- lors d'un appel de fonction, on peut très bien passer un nombre variable de paramètres, récupérés par une liste ( *param) ; ça marche bien. mais, impossible des passer des paramètres nommés
- avec certains langages, comme JScript, on peut aller plus loin, on "connectant" des "objets-COM-callback" sur des objets JScript. On peut ensuite appeler, par callback, des méthodes des objets JScript, ou lire écrire les propriétés, comme s'il s'agissait de propriétés du script Python. Je sais aussi faire ça avec Ruby, Perl, et VBscript, mais uniquement pour des sous-programmes appelés par Python.
- les serveurs COM ont une instance à chaque logiciel langage qui l'ouvre. Ce n'est pas comme avec Word, ou on peut avoir plusieurs logiciels connectés sur le même serveur COM. Néanmoins, si c'est indispensable, j'ai trouvé un moyen d'avoir un serveur COM commun et persistant. Mais c'est un peu tordu : il s'agit d'un pont en HTA (HTml-Application), qui instancie un Internet-Explorer invisible, et lui injecte une référence sur l'objet JScript "pont". On a donc un double-pont persistant. Mais, la contrepartie de cette persistance et de ce partage, c'est la vitesse : 5 fois plus lent que des appels directs.
- les threads fonctionnent bien ; et cela permet d'obtenir des performances apparentes fabuleuses : par exemple : l'utilisateur récupère la main immédiatement, pendant des threads travaillent sur un fichier en PDF, et l'envoi par e-mail (en tâche de fond).
- attention aux problèmes liés aux paramètres de sécurité trop stricts. Il y a encore des gens qui laisse en route le pare-feu standard de windows, alors, qu'ils ont un routeur-parefeu centralisé.
- autre piège : les chaînes de caractères des applications "utilisantes" sont souvent à zéro terminal ; cela peut poser des problèmes, surtout en retour.
- dans certains cas (Paradox+ObjectPAL), c'est réussi à faire fonctionner une DLL d'échange direct de blocs d'octets, entre des variables chaînes, binaires ou graphiques, et des strings Python, grâce à cTypes.
- Python étant aussi un excellent client COM, on peut utiliser un serveur-COM en Python, comme pont d'accès à d'autres logiciels/applications. Cela permet, par exemple, de piloter Word, Excel, Internet-Explorer, OpenOffice.org, etc, depuis des applications qui n'y arriveraient pas autrement.
- On arrive même, grâce à la structure géniale de Python, à faire du debugging ; mais ce n'est pas très simple.
- Mon serveur-COM en Python s'appelle Ponx. J'ai commencé un site dessus : http://ponx.org vous pourriez peut-être l'utiliser. L'avantage, c'est qu'il existe, qu'il tourne depuis plusieurs années, qu'il est extensible avec vos propres modules (comme tout script Python), qu'il existe aussi sous forme de CD auto-installable, qu'il y a une installation en ligne, ainsi que des programmes de mise à jour en ligne. Le problème, c'est la documentation, non terminée, et les exemples, très ciblée Paradox. Il y a aussi un newsgroup (adresse sur le site), pas très animé.
Sur ce, et bien que j'ai oublié plein d'éléments, que je ne vais pas me relire avant de rentrer me coucher, je vous souhaite une bonne nuit.
@-salutations -- Michel Claveau mél : http://cerbermail.com/?6J1TthIa8B
PS : si vous m'envoyez un e-mail, mettez un mot anti-filtre-spam dans l'objet. Par exemple : Python ou Ponx
Sebastien Kirche
On 24 avr, 01:17, "Méta-MCI" wrote:
Bonsoir !
Je profite que l'un des contributeurs du groupe est justement spécialiste des serveurs com en python
J'aimerais bien le rencontrer : ça pourrait être intéressant.
J'ai l'impression que tu es le seul ici à pousser aussi loin python sous windows et c'est bien à toi que je pensais en posant ma question :)
Sinon, quelques infos en vrac :
- il est normal qu'un serveur COM en Python ne soit pas visible dans les browser COM, car il n'y a pas de TLB (Type LiBrary) créé ou génér ée. Ce qui peut sembler un inconvénient peut devenir un avantage, car, avec Python , on peut créer des serveurs COM dynamiques. Par exemple, on peut définir de nouvelles fonctions pendant l'utilisation (chose impossible avec les serveurs statiques, pré-définis dans une TLB). On peut même aller p lus loin, en définissant des fonctions visibles de l'extérieur, qui ne sont m ême pas déclarées dans Python, comme méthodes de la classe COM. Seulement, c'est un peu plus lent ; mais ça permet d'utiliser toutes les fonctions de la librairie standard, comme des fonctions directement utilisables de l'extérieur.
C'est ce que j'avais cru comprendre en ressortant le bon vieux OLEVIEW (outil de visual studio 5 vieux de 10 ans) qui me retrouve tout de même mes classes en compagnie des 3 standards de python (activex scripting engine, dictionary et interpreter) regroupées sous la classe d'objet "Python COM server" alors que les objets qu'on arrive habituellement à invoquer sont listés sous "Types libraries".
Est-ce qu'il n'est pas possible de mettre sous forme de bibliothèque de type un objet python ? C'est pas que j'en aie absolument besoin pour lister les méthodes puisque c'est moi qui en serait à l'origine mais disons que c'est pas curiosité.
[ snip un tas de remarques intéressantes ]
Sur ce, et bien que j'ai oublié plein d'éléments, que je ne vais pa s me relire avant de rentrer me coucher, je vous souhaite une bonne nuit.
Merci pour tes remarques que je me suis empressé de mettre de côté, il y a déjà pas mal de choses. Je vais aussi regarder de plus près ton serveur pour voir comment c'est implémenté.
On 24 avr, 01:17, "Méta-MCI" <enleverlesX.X...@XmclaveauX.com> wrote:
Bonsoir !
Je profite que l'un des contributeurs du groupe est justement
spécialiste des serveurs com en python
J'aimerais bien le rencontrer : ça pourrait être intéressant.
J'ai l'impression que tu es le seul ici à pousser aussi loin python
sous windows et c'est bien à toi que je pensais en posant ma
question :)
Sinon, quelques infos en vrac :
- il est normal qu'un serveur COM en Python ne soit pas visible dans les
browser COM, car il n'y a pas de TLB (Type LiBrary) créé ou génér ée. Ce qui
peut sembler un inconvénient peut devenir un avantage, car, avec Python , on
peut créer des serveurs COM dynamiques. Par exemple, on peut définir de
nouvelles fonctions pendant l'utilisation (chose impossible avec les
serveurs statiques, pré-définis dans une TLB). On peut même aller p lus loin,
en définissant des fonctions visibles de l'extérieur, qui ne sont m ême pas
déclarées dans Python, comme méthodes de la classe COM. Seulement, c'est un
peu plus lent ; mais ça permet d'utiliser toutes les fonctions de la
librairie standard, comme des fonctions directement utilisables de
l'extérieur.
C'est ce que j'avais cru comprendre en ressortant le bon vieux OLEVIEW
(outil de visual studio 5 vieux de 10 ans) qui me retrouve tout de
même mes classes en compagnie des 3 standards de python (activex
scripting engine, dictionary et interpreter) regroupées sous la classe
d'objet "Python COM server" alors que les objets qu'on arrive
habituellement à invoquer sont listés sous "Types libraries".
Est-ce qu'il n'est pas possible de mettre sous forme de bibliothèque
de type un objet python ?
C'est pas que j'en aie absolument besoin pour lister les méthodes
puisque c'est moi qui en serait à l'origine mais disons que c'est pas
curiosité.
[ snip un tas de remarques intéressantes ]
Sur ce, et bien que j'ai oublié plein d'éléments, que je ne vais pa s me
relire avant de rentrer me coucher, je vous souhaite une bonne nuit.
Merci pour tes remarques que je me suis empressé de mettre de côté, il
y a déjà pas mal de choses.
Je vais aussi regarder de plus près ton serveur pour voir comment
c'est implémenté.
Je profite que l'un des contributeurs du groupe est justement spécialiste des serveurs com en python
J'aimerais bien le rencontrer : ça pourrait être intéressant.
J'ai l'impression que tu es le seul ici à pousser aussi loin python sous windows et c'est bien à toi que je pensais en posant ma question :)
Sinon, quelques infos en vrac :
- il est normal qu'un serveur COM en Python ne soit pas visible dans les browser COM, car il n'y a pas de TLB (Type LiBrary) créé ou génér ée. Ce qui peut sembler un inconvénient peut devenir un avantage, car, avec Python , on peut créer des serveurs COM dynamiques. Par exemple, on peut définir de nouvelles fonctions pendant l'utilisation (chose impossible avec les serveurs statiques, pré-définis dans une TLB). On peut même aller p lus loin, en définissant des fonctions visibles de l'extérieur, qui ne sont m ême pas déclarées dans Python, comme méthodes de la classe COM. Seulement, c'est un peu plus lent ; mais ça permet d'utiliser toutes les fonctions de la librairie standard, comme des fonctions directement utilisables de l'extérieur.
C'est ce que j'avais cru comprendre en ressortant le bon vieux OLEVIEW (outil de visual studio 5 vieux de 10 ans) qui me retrouve tout de même mes classes en compagnie des 3 standards de python (activex scripting engine, dictionary et interpreter) regroupées sous la classe d'objet "Python COM server" alors que les objets qu'on arrive habituellement à invoquer sont listés sous "Types libraries".
Est-ce qu'il n'est pas possible de mettre sous forme de bibliothèque de type un objet python ? C'est pas que j'en aie absolument besoin pour lister les méthodes puisque c'est moi qui en serait à l'origine mais disons que c'est pas curiosité.
[ snip un tas de remarques intéressantes ]
Sur ce, et bien que j'ai oublié plein d'éléments, que je ne vais pa s me relire avant de rentrer me coucher, je vous souhaite une bonne nuit.
Merci pour tes remarques que je me suis empressé de mettre de côté, il y a déjà pas mal de choses. Je vais aussi regarder de plus près ton serveur pour voir comment c'est implémenté.
