Problème de return

Le
Méta-MCI \(MVP\)
Bonsoir !

Dans un environnement COM, j'ai une fin de méthode qui me pose problème.


Avec :
vret=(11,22,33)
return (vret)

j'obtiens : 11


Alors que, avec :
vret=(11,22,33)
return [vret]

j'obtiens : ((11, 22, 33),)


Question : comment faire, pour renvoyer un tuple, et non le premier
élément (je rappelle qu'il s'agit d'un retour COM).
Merci d'avance, pour toute suggestion.

@-salutations
--
Michel Claveau
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Amaury Forgeot d'Arc
Le #10687771
Méta-MCI (MVP) a écrit :
Bonsoir !

Dans un environnement COM, j'ai une fin de méthode qui me pose problème.


Avec :
vret=(11,22,33)
return (vret)

j'obtiens : 11


Alors que, avec :
vret=(11,22,33)
return [vret]

j'obtiens : ((11, 22, 33),)


Question : comment faire, pour renvoyer un tuple, et non le premier
élément (je rappelle qu'il s'agit d'un retour COM).
Merci d'avance, pour toute suggestion.



COM ou pas COM, "return (x)" ne retourne pas un tuple contenant l'object x !
c'est seulement un x entre parenthèses, et les parenthèses autour d'une
expression ne changent rien.

Ce qui fait le tuple, c'est la virgule !
return (vret,)

--
Amaury
Méta-MCI \(MVP\)
Le #10851631
Salut !

COM ou pas COM, "return (x)" ne retourne pas un tuple contenant
l'object x ! c'est seulement un x entre parenthèses, et les
parenthèses autour d'une expression ne changent rien.



Ce qui fait le tuple, c'est la virgule !
return (vret,)




D'abord, merci d'avoir répondu à mon message.

Sinon, je sais que return() ne retourne pas un tuple. Mais sous Python
"pur", la virgule n'est pas nécessaire, lorsque l'objet est lui-même un
tuple.

Exemple_1 :
def ftest():
vret=(111,222,333)
return(vret)

print ftest() #donne bien: (111, 222, 333)

et (Exemple_2) :
def ftest():
vret=(111,222,333)
return(vret,)

print ftest() #donnera: ((111, 222, 333),)


Le comportement est différent avec COM ; Exemple_1 donne 111.
En plus, j'ai remarqué que return [11,22,33] retourne (par COM) un
tuple, et non une liste, comme en pur Python.

Pour mon problème, j'ai trouvé une solution, avec deux return différents
et un if pour discriminer le cas :
if type(vret) in (types.TupleType,):


Désolé de ne pas avoir publié la solution hier, mais Internet m'a lâché
(le lâche !) toute la soirée d'hier.


@-salutations
--
Michel Claveau
Pierre Quentel
Le #10858271
On 29 juin, 09:28, "Méta-MCI (MVP)"

Pour mon problème, j'ai trouvé une solution, avec deux return différ ents
et un if pour discriminer le cas :
        if type(vret) in (types.TupleType,):



Juste une petite remarque : la forme recommandée pour tester le type
est plutôt

if isinstance(vret,tuple)

A+
Pierre
Méta-MCI \(MVP\)
Le #11159571
Bonjour !

la forme recommandée pour tester le type est plutôt if
isinstance(vret,tuple)



Effectivement, on voit souvent cette forme. Mais j'ai souvent besoin de
tester l'appartenance à plusieurs types ; alors je préfère systématiser
la forme
... in (types.FunctionType, types.BuiltinFunctionType,
types.MethodType, types.BuiltinMethodType)
(même lorsqu'il n'y a qu'un seul type testé) que je trouve plus légère
qu'une succession de "OR".

De plus, c'était (autrefois, jusqu'à la 2.2) la façon recommandée pour
tester un type. Mais les recommandations fluctuent, et manquent de
stabilité...

@+

Michel Claveau
Kobayashi
Le #11159751
Méta-MCI (MVP) a écrit :
Bonjour !

la forme recommandée pour tester le type est plutôt if
isinstance(vret,tuple)



Effectivement, on voit souvent cette forme. Mais j'ai souvent besoin de
tester l'appartenance à plusieurs types ; alors je préfère systématiser
la forme
... in (types.FunctionType, types.BuiltinFunctionType, types.MethodType,
types.BuiltinMethodType)
(même lorsqu'il n'y a qu'un seul type testé) que je trouve plus légère
qu'une succession de "OR".



isinstance(vret,(tuple, list, ))


De plus, c'était (autrefois, jusqu'à la 2.2) la façon recommandée pour
tester un type. Mais les recommandations fluctuent, et manquent de
stabilité...



Mais ceci n'est apparu qu'en 2.2 :

"Changed in version 2.2: Support for a tuple of type information was added."

A noter que issubclass supporte aussi un tuple comme deuxième
argument ... mais depuis la 2.3 seulement.


@+

Michel Claveau






Amaury Forgeot d'Arc
Le #11165971
Bonsoir,

Kobayashi a écrit :
De plus, c'était (autrefois, jusqu'à la 2.2) la façon recommandée pour
tester un type. Mais les recommandations fluctuent, et manquent de
stabilité...



Mais ceci n'est apparu qu'en 2.2 :

"Changed in version 2.2: Support for a tuple of type information was
added."

A noter que issubclass supporte aussi un tuple comme deuxième
argument ... mais depuis la 2.3 seulement.



J'ai une question annexe à ceux qui chassent le python dans la nature
(moi, j'ai ma version domestique, compilée par mes soins)

Rencontrez-vous souvent de vieilles versions de python, disons 2.3 ou
plus anciennes ?
Cela pose-t-il des problèmes ? (manque de support, de librairies, de
documentation)
Vous est-il possible de les mettre à jour ?

--
Amaury
Kobayashi
Le #11166371
Amaury Forgeot d'Arc a écrit :
Bonsoir,

Kobayashi a écrit :
De plus, c'était (autrefois, jusqu'à la 2.2) la façon recommandée
pour tester un type. Mais les recommandations fluctuent, et manquent
de stabilité...



Mais ceci n'est apparu qu'en 2.2 :

"Changed in version 2.2: Support for a tuple of type information was
added."

A noter que issubclass supporte aussi un tuple comme deuxième
argument ... mais depuis la 2.3 seulement.



J'ai une question annexe à ceux qui chassent le python dans la nature
(moi, j'ai ma version domestique, compilée par mes soins)

Rencontrez-vous souvent de vieilles versions de python, disons 2.3 ou
plus anciennes ?



Dans un de mes projets, je dois assurer le support
redhat 8 livré avec python 2.2.1. Heureusement, les
"new-style classes" sont arrivées en 2.2 sinon j'étais
mal !

Cela pose-t-il des problèmes ? (manque de support, de librairies, de
documentation)



Pas vraiment dans mon cas car la base de tests (et
sa couverture) est assez bonne pour détecter rapidement
l'emploi d'une fonctionnalité non présente en 2.2

Vous est-il possible de les mettre à jour ?




Effectivement, on pourrais aussi livrer une version de
python plus récente avec le produit ... mais ce n'est pas
le choix qui a été fait. Mais bon, j'ai espoir que
début 2009, ils arrêtent de nous faire ch., de nous embêter
avec leur redhat 8 ... et, du coup, ils passeront direct
en python 2.5 ... Ceci dit, pour d'autres client, il faudra
assurer la compatibilité python 2.3.3 de mandrake 10.1 :)
Pierre Maurette
Le #11167471
Amaury Forgeot d'Arc, le 01/07/2008 a écrit :

[...]

Rencontrez-vous souvent de vieilles versions de python, disons 2.3 ou plus
anciennes ?



La version actuelle 2.4.1 de OpenOffice pour Windows embarque un
interprêteur Python en version 2.3.4.

Je viens de constater avec un certain étonnement que la même version de
OpenOffice pour Linux, la version gérée par Ubuntu Hardy x86-64,
propose un interprêteur 2.5.2. C'est la même version que celle
installée sur le système, mais il semble qu'il y ait quand même un
interprêteur propre à OOo. Encore que...

--
Pierre Maurette
Méta-MCI \(MVP\)
Le #11176161
Bonsoir !

Je tombe sur des versions 2.2 (rare), 2.3 (pas souvent), 2.4 (de temps
en temps) ou 2.5 (souvent).
En pratique, il s'agit souvent d'installation que j'avais faites sur des
postes de clients, et sur lesquels je n'étais pas intervenu depuis
plusieurs années.

Si j'ai le temps, je fais les mises à jour. Sinon, ça reste comme c'est
.

@-salutations

Michel Claveau
Méta-MCI \(MVP\)
Le #11176151
Bonsoir !

A noter que la version embarquée de Python dans OOo me pose quelques
problèmes. Il est impossible d'y installer des extensions telles que
PyWin32, sans compromettre l'installation dans le Python "normal" (hors
OOo).

@-salutations

Michel Claveau
Publicité
Poster une réponse
Anonyme