transmission de variables entre deux fonctions (suite...)
6 réponses
E.Bullier
Bonjour à tous.
Je me permets de vos contacter à nouveau car je suis toujours en guerre avec
la transmission de variable...
L'explication de Benoit Huron sur cette liste avait était très claire.
Dans le script que je vous joints ci dessous, j'ai créé plusieurs fonctions.
La fonction splash_win appelle la fonction showRoot qui doit entre autre,
détruire la fenêtre splash.
J'ai bien compris que les variables ne sont accessibles qu'à l'intérieur de
la fonction ou dans le script global.
Dans ce cas, la fonction showRoot ne peut accéder aux variables définies
dans la fonction splash_win que si je les déclare comme globale?
Me voilà donc "obliger de configuer deux variables globales dans splash_win
(photo, car si je ne le fais pas, l'image n'apparait pas dans la fenêtre.
splash, pour pouvoir l'invoquer dans la fonction showRoot).
Je sais que cela est déconseillé.
Alors, j'en appelle à votre sagacité; comment régler ces problèmes sans
utiliser de variables globales?...
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
huron benoit
E.Bullier wrote:
Me voilà donc "obliger de configuer deux variables globales dans splash_win (photo, car si je ne le fais pas, l'image n'apparait pas dans la fenêtre. splash, pour pouvoir l'invoquer dans la fonction showRoot). Je sais que cela est déconseillé. Alors, j'en appelle à votre sagacité; comment régler ces problèmes sans utiliser de variables globales?...
Definis ta fonction show_root à l'intérieur de ta fonction splash_win. Depuis Python 2.1, les portées dans lesquelles Python recherche les noms d'objet peuvent être imbriquées, cela se dit en anglais : lexically nested scopes (d'abord portée locale, puis portée supérieure -autant qu'il y a en a-, puis portée globale, puis built-ins.
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de définir une classe.
Benoît.
P.S Au lieu de mettre les meta-data de ton fichier (ou module) en commentaire, documente ton code comme ceci :
__author__ = "Raistlin" __version__= "185.4"
etc...
E.Bullier wrote:
Me voilà donc "obliger de configuer deux variables globales dans splash_win
(photo, car si je ne le fais pas, l'image n'apparait pas dans la fenêtre.
splash, pour pouvoir l'invoquer dans la fonction showRoot).
Je sais que cela est déconseillé.
Alors, j'en appelle à votre sagacité; comment régler ces problèmes sans
utiliser de variables globales?...
Definis ta fonction show_root à l'intérieur de ta fonction splash_win.
Depuis Python 2.1, les portées dans lesquelles Python recherche les noms
d'objet peuvent être imbriquées, cela se dit en anglais : lexically
nested scopes (d'abord portée locale, puis portée supérieure -autant
qu'il y a en a-, puis portée globale, puis built-ins.
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de
définir une classe.
Benoît.
P.S Au lieu de mettre les meta-data de ton fichier (ou module) en
commentaire, documente ton code comme ceci :
Me voilà donc "obliger de configuer deux variables globales dans splash_win (photo, car si je ne le fais pas, l'image n'apparait pas dans la fenêtre. splash, pour pouvoir l'invoquer dans la fonction showRoot). Je sais que cela est déconseillé. Alors, j'en appelle à votre sagacité; comment régler ces problèmes sans utiliser de variables globales?...
Definis ta fonction show_root à l'intérieur de ta fonction splash_win. Depuis Python 2.1, les portées dans lesquelles Python recherche les noms d'objet peuvent être imbriquées, cela se dit en anglais : lexically nested scopes (d'abord portée locale, puis portée supérieure -autant qu'il y a en a-, puis portée globale, puis built-ins.
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de définir une classe.
Benoît.
P.S Au lieu de mettre les meta-data de ton fichier (ou module) en commentaire, documente ton code comme ceci :
__author__ = "Raistlin" __version__= "185.4"
etc...
Yann.K
huron benoit wrote:
Definis ta fonction show_root à l'intérieur de ta fonction splash_win. Depuis Python 2.1, les portées dans lesquelles Python recherche les noms d'objet peuvent être imbriquées, cela se dit en anglais : lexically nested scopes (d'abord portée locale, puis portée supérieure -autant qu'il y a en a-, puis portée globale, puis built-ins. OK, mais cela limite l'utilisation des fonctions imbriquées à la fonction
imbriquante. Ce qui restreind l'utilisation de fonction , non?
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de définir une classe. ...mouais
P.S Au lieu de mettre les meta-data de ton fichier (ou module) en commentaire, documente ton code comme ceci :
__author__ = "Raistlin" __version__= "185.4" OK, je ne suis pas encore tombé sur les pages de doc explicitant ces
détails ;-) J'aurais d'ailleurs bien aimé trouver une bonne doc décrivant "la bonne" méthode d'écriture de script py (commentaire, nbre de saut de ligne entres blocs, en-tête, en bref les conventions/normalisations d'écriture).
Merci encore de ces précieux conseils.
-- Yann.K
huron benoit wrote:
Definis ta fonction show_root à l'intérieur de ta fonction splash_win.
Depuis Python 2.1, les portées dans lesquelles Python recherche les noms
d'objet peuvent être imbriquées, cela se dit en anglais : lexically
nested scopes (d'abord portée locale, puis portée supérieure -autant
qu'il y a en a-, puis portée globale, puis built-ins.
OK, mais cela limite l'utilisation des fonctions imbriquées à la fonction
imbriquante.
Ce qui restreind l'utilisation de fonction , non?
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de
définir une classe.
...mouais
P.S Au lieu de mettre les meta-data de ton fichier (ou module) en
commentaire, documente ton code comme ceci :
__author__ = "Raistlin"
__version__= "185.4"
OK, je ne suis pas encore tombé sur les pages de doc explicitant ces
détails ;-)
J'aurais d'ailleurs bien aimé trouver une bonne doc décrivant "la bonne"
méthode d'écriture de script py (commentaire, nbre de saut de ligne entres
blocs, en-tête, en bref les conventions/normalisations d'écriture).
Definis ta fonction show_root à l'intérieur de ta fonction splash_win. Depuis Python 2.1, les portées dans lesquelles Python recherche les noms d'objet peuvent être imbriquées, cela se dit en anglais : lexically nested scopes (d'abord portée locale, puis portée supérieure -autant qu'il y a en a-, puis portée globale, puis built-ins. OK, mais cela limite l'utilisation des fonctions imbriquées à la fonction
imbriquante. Ce qui restreind l'utilisation de fonction , non?
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de définir une classe. ...mouais
P.S Au lieu de mettre les meta-data de ton fichier (ou module) en commentaire, documente ton code comme ceci :
__author__ = "Raistlin" __version__= "185.4" OK, je ne suis pas encore tombé sur les pages de doc explicitant ces
détails ;-) J'aurais d'ailleurs bien aimé trouver une bonne doc décrivant "la bonne" méthode d'écriture de script py (commentaire, nbre de saut de ligne entres blocs, en-tête, en bref les conventions/normalisations d'écriture).
Merci encore de ces précieux conseils.
-- Yann.K
Yann.K
Yann.K wrote:
J'aurais d'ailleurs bien aimé trouver une bonne doc décrivant "la bonne" méthode d'écriture de script py (commentaire, nbre de saut de ligne entres blocs, en-tête, en bref les conventions/normalisations d'écriture). Je me réponds car je pense que ça peut intéresser d'autres personnes:
http://www.python.org/peps/pep-0008.html
-- Yann.K
Yann.K wrote:
J'aurais d'ailleurs bien aimé trouver une bonne doc décrivant "la bonne"
méthode d'écriture de script py (commentaire, nbre de saut de ligne entres
blocs, en-tête, en bref les conventions/normalisations d'écriture).
Je me réponds car je pense que ça peut intéresser d'autres personnes:
J'aurais d'ailleurs bien aimé trouver une bonne doc décrivant "la bonne" méthode d'écriture de script py (commentaire, nbre de saut de ligne entres blocs, en-tête, en bref les conventions/normalisations d'écriture). Je me réponds car je pense que ça peut intéresser d'autres personnes:
http://www.python.org/peps/pep-0008.html
-- Yann.K
LioneL
Je me réponds car je pense que ça peut intéresser d'autres personnes: http://www.python.org/peps/pep-0008.html
et ici une traduction en français (un peu ancienne !):
http://lapagearegis.free.fr/guidedestyle.html
lionel -- Python facile : http://lionel.grolleau.free.fr/ Les ressources (liens) en français sur Python. Python et l'unicode ou comment afficher les caractères accentués dans un terminal 'DOS'.
Je me réponds car je pense que ça peut intéresser d'autres personnes:
http://www.python.org/peps/pep-0008.html
et ici une traduction en français (un peu ancienne !):
http://lapagearegis.free.fr/guidedestyle.html
lionel
--
Python facile : http://lionel.grolleau.free.fr/
Les ressources (liens) en français sur Python.
Python et l'unicode ou comment afficher les caractères accentués dans un
terminal 'DOS'.
Je me réponds car je pense que ça peut intéresser d'autres personnes: http://www.python.org/peps/pep-0008.html
et ici une traduction en français (un peu ancienne !):
http://lapagearegis.free.fr/guidedestyle.html
lionel -- Python facile : http://lionel.grolleau.free.fr/ Les ressources (liens) en français sur Python. Python et l'unicode ou comment afficher les caractères accentués dans un terminal 'DOS'.
huron benoit
Yann.K wrote:
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de définir une classe.
...mouais
Il me semblait bien que j'avais ça quelque part ... : http://www.ferg.org/thinking_in_tkinter/index.html
Ce tutorial semble répondre à bon nombre de vos interrogations (avec clarté et exemples). Faites surtout attention aux programmes tt035.py (sur la structure de classe) et tt076.py - tt079.py (sur les transmissions d'arguments). Retenez surtout une chose. Il y a plusieurs façon de résoudre un problème, plusieurs techniques. Python n'est (heureusement) pas une exception..
Benoît.
Yann.K wrote:
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de
définir une classe.
...mouais
Il me semblait bien que j'avais ça quelque part ... :
http://www.ferg.org/thinking_in_tkinter/index.html
Ce tutorial semble répondre à bon nombre de vos interrogations (avec
clarté et exemples). Faites surtout attention aux programmes tt035.py
(sur la structure de classe) et tt076.py - tt079.py (sur les
transmissions d'arguments).
Retenez surtout une chose. Il y a plusieurs façon de résoudre un
problème, plusieurs techniques. Python n'est (heureusement) pas une
exception..
Mais je n'aime pas cette solution. Il faudrait peut-être envisager de définir une classe.
...mouais
Il me semblait bien que j'avais ça quelque part ... : http://www.ferg.org/thinking_in_tkinter/index.html
Ce tutorial semble répondre à bon nombre de vos interrogations (avec clarté et exemples). Faites surtout attention aux programmes tt035.py (sur la structure de classe) et tt076.py - tt079.py (sur les transmissions d'arguments). Retenez surtout une chose. Il y a plusieurs façon de résoudre un problème, plusieurs techniques. Python n'est (heureusement) pas une exception..
Benoît.
Yann.K
huron benoit wrote:
Yann.K wrote: Il me semblait bien que j'avais ça quelque part ... : http://www.ferg.org/thinking_in_tkinter/index.html OK, maginfique.
J'ai pris le temps de tout lire, digérer et refaire tous les exemples...
J'ai passé mes modules en classes et, miracle, je peux supprimer toutes les variales globales et les scripts fonctionnent toujours! Le rêve quoi.
La gestion des espaces mémoires est grandement facilitée par l'utilisation des classes.
Merci encore pour cet excellent lien. -- Yann.K
huron benoit wrote:
Yann.K wrote:
Il me semblait bien que j'avais ça quelque part ... :
http://www.ferg.org/thinking_in_tkinter/index.html
OK, maginfique.
J'ai pris le temps de tout lire, digérer et refaire tous les exemples...
J'ai passé mes modules en classes et, miracle, je peux supprimer toutes les
variales globales et les scripts fonctionnent toujours!
Le rêve quoi.
La gestion des espaces mémoires est grandement facilitée par l'utilisation
des classes.