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.
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
Amaury Forgeot d'Arc
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) 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,)
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\)
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.
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
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.
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.
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.
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
On 29 juin, 09:28, "Méta-MCI (MVP)" wrote:
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
On 29 juin, 09:28, "Méta-MCI (MVP)"
<enleverlesX.X...@XmclaveauX.com> wrote:
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
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\)
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
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é...
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
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
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.
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
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
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 ?
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
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 :)
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 :)
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
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
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...
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\)
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
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
.
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\)
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
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).
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).
