#!/usr/bin/env python
a = 10
def toto():
____print a

#!/usr/bin/env python
import toto

toto.a = 5
toto.toto()

Citation
tuxfanch
1A) Je pense que oui, mais je suis pas sûr de bienvoir ce que tu veux.

class xxx {
____static int v;
};
xxx::v=10;

Citation
tuxfanch
2A) Je me lamentait du contraire hier avec du QT/Cxx. Bah non, faut toujours mettre self, et personnellement je trouve ça pratique et bienvenu.

Citation
tuxfanch
3A) ah bah ouais mais bon, c'est du TkInter je
suppose. J'aime pas TkInter. Désolé, je n'ai pas
de réponse à ça (PyQT c'est ouachement mieux)

Citation
tuxfanch
4A) c'est normal ! tu te rend compte que dans
toto, tu fais appel à une variable totalement
inconnue ! tu peux faire ça :
toto.py
#!/usr/bin/env python
a = 10
def toto():
____print a

main.py
#!/usr/bin/env python
import toto

toto.a = 5
toto.toto()

def toto():
____print a

def titi():
____print a

a=10
toto()
titi()

#!/usr/bin/env python

valeur = 0

def set_valeur(int pin_val):
____global valeur
____valeur = pin_val

def get_valeur():
____global valeur
____return(valeur)

Citation
tuxfanch
Je vois bien qu'elles te manquent ces saloperies de variables globales. Si si, moi aussi je code sur une appli en C, je vois très bien où tu veux
en venir ! hmmm .... il faut juste un petit extern
dans le header et en voiture simone ... bah pense
à moi : j'ai plus de 800 variables globales dans
un peu plus d'une centaine de *.c et autant de *.h
donc Je souffre atrocement de ces de fonctions
qui mettent à jour une pagaille de variables
globales n'importe où et n'importe comment.
Alors Python c'est du bonheur : du code qu'on
comprend comme on lit le journal ! aaaaaah (je
sais, le C bien écrit se comprend très facilement,
même sans commentaires. Mais le C bien écrit,
c'est comme le père Noël)

#define VAL_IN      0x01 
#define VAL_OUT     0x02 
#define VAL_OVER    0x03 
 
int f(...) 
{ 
____if (...) return VAL_IN; 
____if (...) return VAL_OUT; 
____return VAL_OVER; 
} 
 
main() 
{ 
____switch(f(...)) 
____{ 
________case VAL_IN: 
____________<...a...> 
________case VAL_OUT: 
____________<...b...> 
________case VAL_OVER: 
____________<...c...> 
____} 
}

define={ 
____"val" : { "in" : 0x01, "out" : 0x02, "over" : 0x03}
____# Eventuellement d'autres macro à suivre... 
} 
 
def f(...): 
____if ...: 
________return define["val"]["in"] 
____if ...: 
________return define["val"]["out"] 
____return define["val"]["over"] 
 
if f() == define["val"]["in"]: 
____<...a...> 
elif f() == define["val"]["out"]: 
____<...b...> 
elif f() == define["val"]["over"]: 
____<...c...>

Citation
tuxfanch
Mais le C bien écrit, c'est comme le père Noël

from sys import setrecursionlimit
setrecursionlimit(10000)

Citation
AlSim
Pour le 5, je n'ai jamais trop aimé le after(50,
move) de cet exemple ...

Citation
AlSim
Pour la limite de récursion, elle est il me semble de 1000 itérations par défaut, mais heureusement réglable (et souvent trop basse) :

from sys import setrecursionlimit
setrecursionlimit(10000)

Citation
AlSim
Quand je dis que je n'aime pas le after(50,move),
c'est parce que ça me fait trop penser à une sorte
de goto, j'aurais préféré une structure itérative
ici.

Citation
miguel2i
C'est pas de la récursivité, move ne s'appele pas directement.

Comme tout les Tk, Qt, Gtk, et autres, il y a une
fonction d'attente d'événnements (que j'appelerais
ici main_loop).

main_loop appele la fonction move (quand on clique
sur le bouton start)
move ajoute un évènnement à la fonction main_loop
Quand l'évènnement arrive, main_loop appele move

Quand le deuxième move est appelé le premier move
est terminé depuis longtemps.

Citation
AlSim
Je n'ai pas python sous la main, mais je pense que
bool and v1 or v2 ne remplace bool ?v1 :v2 que
dans le cas où v1 et v2 sont eux-mêmes des
booléens, puisque cette syntaxe renverra toujours
des booléens. Il faudrait alors utiliser bool and
a=v1 or a=v2, ce qui perd un peu d'intéret.

Citation
miguel2i
bool and v1 or v2

Citation
miguel2i
C'est pas de la récursivité, move ne s'appele pas
directement.

Comme tout les Tk, Qt, Gtk, et autres, il y a une
fonction d'attente d'événnements (que j'appelerais
ici main_loop).

main_loop appele la fonction move (quand on clique
sur le bouton start)
move ajoute un évènnement à la fonction main_loop
Quand l'évènnement arrive, main_loop appele move

Quand le deuxième move est appelé le premier move
est terminé depuis longtemps.

Citation
AlSim
Si je comprends bien moi-même, fen1.after(50,move)
ne lance pas move : ça met un évènement "lancement
de loop" en queue dans la boucle principale du
widget fen1. Puis, comme il n'y a plus
d'instructions, le premier move se termine. 50 ms
plus tard, l'évènement se déclanche et appelle
move à nouveau, et ce n'est pas move s'appelle
elle-même mais bien la boucle principale.

// Fonction qui est appelée lors d'un signal s
xxx(int s)
{
....// Elle se réarme en cas de nouveau signal
....signal(s, xxx);

....// Code utile
....<...>
}

int main()
{
....// On prépare l'appel à "xxx" en cas de signal 15
....signal(15, xxx);

....// Code principal
....<...>
}

mainloop() 
boucle infini:
si un évenement souris est survenu
    si un boutton a été cliqué
        appeler la fonction associé (callback)
    (donc dans notre cas)
    si le boutton start a été cliqué 
        appeler start_it()
    si le boutton stop a été cliqué
        appeler stop_it()
si il y a des minuteries
   si une minuterie est dépassé
      appeler la fonction associé
   (dans notre cas)
   si la minuterie appelée dans move() est dépassé
     appeler move()
si l'evenement "fermer la fenetre" est survenu
    quitter la boucle
si un évenement clavier est survenu
   ...
si autres evenements 
    ...
fin de boucle infini

Citation
miguel2i
Ca ressemble aux signaux sauf qu'ici on sait quand
la fonction est appelée.
la fonction after est une minuterie (appele la
fonction xxx dans x secondes)