Lister les objets d'une certaine classe ?

Le
Etienne
Bonjour à tous,

J'ai deux peines:
- Je suis à moitié débutant (autant en Python qu'en développement)
- Je suis condamné à utiliser DDE pour communiquer avec un soft
propriétaire.

Ma question, en version courte: Y'a-t'il un moyen simple de lister les
objets créés dans Python?

En version longue: Si j'ai bien compris, DDE est un protocole de
communication entre applications qui s'abstient de définir un serveur
et un client: Toutes les applications qui communiquent sont vues comme
des serveurs qui initient des "conversations" les unes avec les autres.
Pywin32 contient tout ce qu'il faut pour faire ça, 'import win32ui, dde'
et c'est parti (bien que ça ne marche pour l'instant qu'en Python2.7
32 bits).

J'arrive très bien à créer un objet conversation pour passer des requêtes
à mon soft propriétaire: Cet objet créé un serveur appelé "Python", et
initialise la conversation à partir de celui-ci. Là où ça se gâte, c'est
quand je veux créér une deuxième conversation: je voudrais avoir la liberté
de la démarrer à partir d'un serveur existant, ou de créer un autre serveur.
Pour celà, il faut que je sache quels sont les serveurs existant, soit
pour y attacher une conversation, soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant. Est-ce qu'il est donc possible
de lister les objets existants ? Alternativement, j'ai pensé que je
pourrais lister mes serveurs dans une variable globale, mais il me semble
que ça n'est pas recommandé.

Une suggestion ? Un pointeur vers une doc ?

--
Étienne
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas
Le #25185482
Le 30/01/2013 10:43, Etienne a écrit :
Bonjour à tous,

J'ai deux peines:
- Je suis à moitié débutant (autant en Python qu'en développement)
- Je suis condamné à utiliser DDE pour communiquer avec un soft
propriétaire.

Ma question, en version courte: Y'a-t'il un moyen simple de lister les
objets créés dans Python?

En version longue: Si j'ai bien compris, DDE est un protocole de
communication entre applications qui s'abstient de définir un serveur
et un client: Toutes les applications qui communiquent sont vues comme
des serveurs qui initient des "conversations" les unes avec les autres.
Pywin32 contient tout ce qu'il faut pour faire ça, 'import win32ui, dde'
et c'est parti (bien que ça ne marche pour l'instant qu'en Python2.7
32 bits).

J'arrive très bien à créer un objet conversation pour passer des requêtes
à mon soft propriétaire: Cet objet créé un serveur appelé "Python", et
initialise la conversation à partir de celui-ci. Là où ça se gâte, c'est
quand je veux créér une deuxième conversation: je voudrais avoir la liberté
de la démarrer à partir d'un serveur existant, ou de créer un autre serveur.
Pour celà, il faut que je sache quels sont les serveurs existant, soit
pour y attacher une conversation, soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant. Est-ce qu'il est donc possible
de lister les objets existants ? Alternativement, j'ai pensé que je
pourrais lister mes serveurs dans une variable globale, mais il me semble
que ça n'est pas recommandé.

Une suggestion ? Un pointeur vers une doc ?




Le plus simple est de créer des noms de serveur avec une partie fixe
"Python" et une partie aléatoire.

Nicolas
Etienne
Le #25185592
Ce bavard de Nicolas vient de nous dire:

Salut,

Pour celà, il faut que je sache quels sont les serveurs existant, soit
pour y attacher une conversation, soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant. Est-ce qu'il est donc
possible de lister les objets existants ? Alternativement, j'ai pensé
que je pourrais lister mes serveurs dans une variable globale, mais il
me semble que ça n'est pas recommandé.

Une suggestion ? Un pointeur vers une doc ?



Le plus simple est de créer des noms de serveur avec une partie fixe
"Python" et une partie aléatoire.



Ça, ça me permet d'éviter les conflits à la création d'un nouveau
serveur, mais pas d'attacher une conversation à un serveur existant.
Est-ce que tu es en train de me suggérer de ne pas m'en préoccupper,
et de créér de toutes façons un serveur par conversation ? Je ne
trouve pas ça très propre, mais je suis peut-être tatillon ...

--
Étienne
Alain Ketterlin
Le #25185702
Etienne
Pour celà, il faut que je sache quels sont les serveurs existant, soit
pour y attacher une conversation, soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant. Est-ce qu'il est donc
possible de lister les objets existants ? Alternativement, j'ai pensà ©
que je pourrais lister mes serveurs dans une variable globale, mais il
me semble que ça n'est pas recommandé.



Le plus simple est de créer des noms de serveur avec une partie fix e
"Python" et une partie aléatoire.



Ça, ça me permet d'éviter les conflits à la créa tion d'un nouveau
serveur, mais pas d'attacher une conversation à un serveur existant.



Si tu veux récupérer un serveur existant, il faut bien le garder quelque
part. Il n'y a pas de listes d'instances maintenue automatiquement, ce
sera à ton code de la maintenir. Après, que ce soit une variable globale
ou pas dépend du reste de ton modèle de données.

-- Alain.
Nicolas
Le #25189192
Le 31/01/2013 10:58, Etienne a écrit :
Ce bavard de Nicolas vient de nous dire:

Salut,

Pour celà, il faut que je sache quels sont les serveurs existant, soit
pour y attacher une conversation, soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant. Est-ce qu'il est donc
possible de lister les objets existants ? Alternativement, j'ai pensé
que je pourrais lister mes serveurs dans une variable globale, mais il
me semble que ça n'est pas recommandé.

Une suggestion ? Un pointeur vers une doc ?



Le plus simple est de créer des noms de serveur avec une partie fixe
"Python" et une partie aléatoire.



Ça, ça me permet d'éviter les conflits à la création d'un nouveau
serveur, mais pas d'attacher une conversation à un serveur existant.
Est-ce que tu es en train de me suggérer de ne pas m'en préoccupper,
et de créér de toutes façons un serveur par conversation ? Je ne
trouve pas ça très propre, mais je suis peut-être tatillon ...



Non, c'était pour répondre à ", soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant".
Le mieux étant, bien sûr, de réutiliser ce qui peux l'être. Là, pas de
miracle. A toi de garder en mémoire ce qui doit l'être. Mais peut-être
que l'API de la librairie que tu utilises le fait déjà ?

Nicolas
Etienne
Le #25189312
Ce bavard de Nicolas vient de nous dire:

Est-ce que tu es en train de me suggérer de ne pas m'en préoccupper,
et de créér de toutes façons un serveur par conversation ? Je ne
trouve pas ça très propre, mais je suis peut-être tatillon ...



Non, c'était pour répondre à ", soit pour en créer un autre en évitant
de lui donner le nom d'un serveur existant".
Le mieux étant, bien sûr, de réutiliser ce qui peux l'être. Là, pas de
miracle. A toi de garder en mémoire ce qui doit l'être. Mais peut-être
que l'API de la librairie que tu utilises le fait déjà ?



Pas que j'ai vu, mais je vais re-vérifier. Merci, en tout cas, c'est
déjà des éléments de réponse.

--
Étienne
Etienne
Le #25189322
Ce bavard de Alain Ketterlin vient de nous dire:

Ça, ça me permet d'éviter les conflits à la création d'un nouveau
serveur, mais pas d'attacher une conversation à un serveur existant.



Si tu veux récupérer un serveur existant, il faut bien le garder quelque
part. Il n'y a pas de listes d'instances maintenue automatiquement, ce
sera à ton code de la maintenir. Après, que ce soit une variable globale
ou pas dépend du reste de ton modèle de données.



Ok, merci. C'était peut-être évident, mais je découvre, hein !

Je crois que l'imbrication des classes va me permettre de faire les
choses proprement, si j'en crois ce commentaire (Ça aussi, c'est nouveau
pour moi):
http://stackoverflow.com/a/78868

--
Étienne
Nicolas
Le #25199222

Je crois que l'imbrication des classes va me permettre de faire les
choses proprement, si j'en crois ce commentaire (Ça aussi, c'est nouveau
pour moi):
http://stackoverflow.com/a/78868



Commencer à utiliser un langage en utilisant des classes imbriquées
n'est pas ce qu'il y a de plus facile. Il faut déjà bien comprendre
l'espace de nommage du langage. Il ne faut pas non plus confondre avec
l'héritage de classe qui est beaucoup plus utilisé.
Une bonne architecture logicielle, c'est 50% du travail de fait.

Nicolas
Etienne
Le #25199722
Ce bavard de Nicolas vient de nous dire:

Commencer à utiliser un langage en utilisant des classes imbriquées
n'est pas ce qu'il y a de plus facile. Il faut déjà bien comprendre
l'espace de nommage du langage. Il ne faut pas non plus confondre avec
l'héritage de classe qui est beaucoup plus utilisé.



J'ai sûrement confondu. Je tâtonne, j'essaye, ... Quand on n'a pas la
formation théorique, c'est forcément plus long et laborieux. :-/

Merci quand même.

--
Étienne
Nicolas
Le #25201912
Le 04/02/2013 15:31, Etienne a écrit :
Ce bavard de Nicolas vient de nous dire:

Commencer à utiliser un langage en utilisant des classes imbriquées
n'est pas ce qu'il y a de plus facile. Il faut déjà bien comprendre
l'espace de nommage du langage. Il ne faut pas non plus confondre avec
l'héritage de classe qui est beaucoup plus utilisé.



J'ai sûrement confondu. Je tâtonne, j'essaye, ... Quand on n'a pas la
formation théorique, c'est forcément plus long et laborieux. :-/

Merci quand même.



Le théorie c'est bien mais sans pratique...
Je commencerais par lire un/des bouquins sur le langage lui-même.
Ca permet d'avoir une idée de ce que l'on peut faire avec celui-ci.
Faire quelques exercices simples en simultané permet de bien assimiler
les concepts et spécificités du langage.
Une fois que tu connais le langage, que tu sais ce qu'il peut faire,
alors tu peux te lancer dans la programmation d'une application en
commençant par réfléchir à son architecture interne.
Tu peux aussi poser des questions ici.

Nicolas
Etienne
Le #25202702
Ce bavard de Nicolas vient de nous dire:

Le théorie c'est bien mais sans pratique...
Je commencerais par lire un/des bouquins sur le langage lui-même.



En fait, je viens de finir "Learning Python The Hard Way". Il n'a pas
de tome II, visiblement. :-)

Une fois que tu connais le langage, que tu sais ce qu'il peut faire,
alors tu peux te lancer dans la programmation d'une application en
commençant par réfléchir à son architecture interne.



Ce que je comprends, c'est que entre le niveau débutant-qui-a-lu-un-
bouquin-sur-le-sujet et utilisateur-qui-maitrise-le-sujet, il y a un
trou qu'on ne comble qu'avec de l'expérience.

Tu peux aussi poser des questions ici.



Oui, vraisemblablement j'en aurai d'autres. ;-)

--
Étienne
Publicité
Poster une réponse
Anonyme