/* Topic des codeurs couche-tard [5] */

tshirtman · Le 21/08/2011, à 15:56

@ArkSeth: je pense que c'est le module "pickle" que tu veux

Pylades · Le 21/08/2011, à 16:06

ArkSeth a écrit :

Je déclare l'objet comme héritant de gtk.VBox, puis je commence à définir sa méthode __init__ à lui pour l'initialiser (methode appelée, théoriquement, après que le __new__() ait été appelé).
J'ai déjà fait l'essai de ne pas mettre la 3e ligne, ça râlait que mon objet n'était pas vraiment une VBox (ou autre chose dans l'autre cas, mais bref) : j'en ai donc déduit que l'appel à l'initialiseur parent ne se faisait pas automatiquement.
J'ai donc cherché comment faire, et la méthode que j'ai trouvé à été celle-ci : appeler la méthode désirée en la préfixant du nom de la classe dans laquelle je vais la chercher, et en lui spécifiant donc self comme paramètre, vu qu'il faut bien le donner quelque part.
De ce que j'ai constaté, les deux sortes d'appel, objet.methode() et Classe.methode(objet) sont rigoureusement identiques quand objet est de type Classe, mais permettent d'appeler, sur un objet, une méthode d'une autre classe… par exemple une classe parente comme ici.
Il s'agit donc simplement de spécifier qu'à cet endroit précis, j'ai besoin qu'il utilise une méthode de la classe-mère et non une de celle de la classe-fille (Cette manière de procédé sert aussi en cas d'héritage multiple, quand deux classes mères ont la même méthode, pour préciser dans la classe fille à laquelle des deux on fait appel, j'pense).

Ah ouais, vu comme ça, ça se défend (surtout maintenant que je suis reposé) ; mais je trouve quand même ça pas vraiment élégant. Je vais essayer de voir si l’on peut faire autrement.

ArkSeth a écrit :

Tiens, dis, désolé pour le double-post, mais encore une question saugrenue (d'ailleurs, j'en ai une qui attend ci-dessus les habitués de chroot ) : y a-t-il moyen d'enregistrer dans un fichier des instances d'objets python, pour les retrouver sans avoir besoin de les recréer quand on relancera le programme ?
En gros, j'voudrais faire une gestion de sessions, et je voudrais savoir si je dois me faire un fichier de config au format texte où je dois entrer toutes les informations qui me serviront à recréer de nouveaux objets, ou si je ne peux pas réutiliser un truc tout fait.
J'ai vaguement apprit les bases de comment faire de la sérialisation en Java, mais en Python, jamais entendu parler.

Je crois bien avoir vu un truc du genre, mais je serais incapable de donner le nom du module. Je vais quand même essayer de m’en souvenir.

Et voici ce que j’appelle un aspect hideux quand touhy est lancé par autostart.sh sans sleep ou avec un timeout insuffisant (cela dit, ce coup-ci l’icône de la batterie est correcte) :

Des icônes que je n’aime pas et qui sont même carrément dégueulasses pour certaines.
Normalement, ça fait ça :

Édit :

tshirtman a écrit :

@ArkSeth: je pense que c'est le module "pickle" que tu veux

Ah, oui, c’était ça ! \o/

Dernière modification par Πυλάδης (Le 21/08/2011, à 16:07)

Elzen · Le 21/08/2011, à 16:37

@tshirtman : merci, j'vais essayer de jeter un œil à comment ça marche

Πυλάδης a écrit :

Et voici ce que j’appelle un aspect hideux quand touhy est lancé par autostart.sh sans sleep ou avec un timeout insuffisant (cela dit, ce coup-ci l’icône de la batterie est correcte) :

Des icônes que je n’aime pas et qui sont même carrément dégueulasses pour certaines.
Normalement, ça fait ça :

Ah ouais, en effet

C'est… très curieux, comme affaire.
Tu utilises un daemon genre gnome-settings-daemon pour gérer le thème gtk ?

Nan, parce qu'a priori, s'il ne prend pas les bonnes icônes, c'est qu'il ne lit pas correctement le fichier ~/.gtkrc-2.0 qui permet de définir le thème d'icônes à utiliser. Or, en l'absence de daemon, ce fichier est juste censé être présent en permanence, donc lu quel que soit la manière de lancer l'exécutable…
Et comme j'suis pas sûr de savoir comment le daemon communique avec l'appli pour lui dire de prendre tel ou tel thème, j'ai pas du faire ce qu'il faut pour que ça change d'icônes dans ce cas-là.

Ceci dit, j'ai commencé à intégrer la possibilité de définir des fichiers gtkrc (placés dans le répertoire de config de touhy, donc spécifiques à lui) personnalisés pour certaines composantes de l'environnement (pour être précis, c'est fait pour le terminal et les embryons de début de navigateurs (web et de fichier), et pour l'exécutable qui lance tout l'environnement, mais j'ai pas encore eu le courage de prendre les différents exécutables séparés pour leur rajouter leur truc spécifique).
Comme ça, on peut définir un thème spécifique pour chaque composant de Touhy, c'est assez inutile, mais ça peut faire sympa (genre j'ai présentement des icônes en rouge sur mon bureau et dans mon menu alors qu'elles sont bleues pour les applis extérieures à Touhy)

Sinon, j'veux bien des précisions pour le reste de mes demandes d'éclaircissements d'hier soir

Dernière modification par ArkSeth (Le 21/08/2011, à 16:38)

Pylades · Le 21/08/2011, à 17:07

Alors, ouais, juste avant de lire ta réponse je me suis souvenu que j’utilisais gnome-settings-daemon, et comme toi je le soupçonne plus que fortement. Affaire résolue, je pense.

Sinon, je vais éclaircir dans la soirée, je pense.

Ah, et j’ai changé quelques trucs dans le code de Touhy, je veux bien savoir ce que tu en penses :

diff --git a/devutils/__init__.py b/devutils/__init__.py
index ea509a6..3a8eac6 100644
--- a/devutils/__init__.py
+++ b/devutils/__init__.py
@@ -12,7 +12,6 @@ sys.path[0] = cpath
 cfile = "behaviors.list"
 csect = "devutils"
 
-global modactive
 modactive = False
 
 # Valeurs considérées comme vraies (le reste vaut faux).
@@ -26,7 +25,7 @@ if (rewrite): settings.save(cfile)
 def manage(filename, section, option, value):
     if (option == "laptray"):
         global modactive
-        value = valtrue.__contains__(value)
+        value = value in valtrue
         if (value and not modactive):
             laptray.trayicon.set_visible(True)
             modactive = True
diff --git a/devutils/__init__.pyc b/devutils/__init__.pyc
index 16d21f0..d9f7600 100644
Binary files a/devutils/__init__.pyc and b/devutils/__init__.pyc differ
diff --git a/devutils/battery.py b/devutils/battery.py
index 080b97a..68067bb 100755
--- a/devutils/battery.py
+++ b/devutils/battery.py
@@ -1,7 +1,7 @@
 #! /usr/bin/python
 # coding: Utf-8
 
-import os, sys, gtk, time, signal, gobject, commands, optparse
+import os, sys, re, gtk, time, signal, gobject, commands, optparse
 
 opath = sys.path[0][:sys.path[0].rfind("/")]
 
@@ -32,21 +32,21 @@ class Battery:
     def glimpse(self):
         self.timer = time.time()+2
         gobject.timeout_add_seconds(2, self.delay)
-        infos = commands.getoutput("acpi -b").split()
+        infostr = commands.getoutput("acpi -b")
+        infos = infostr.split()
+        re_level = re.search(r"(\d+)%", infostr)
+        level = int(re_level.group(1)) if re_level else 0
         baticon = gtk.gdk.pixbuf_new_from_file(opath+"/ressources/icons/battery.png")
         if (len(infos) < 3): # Pas de batterie, mais une icône est demandée.
             icon = baticon.rotate_simple(180)
-            level = 0
             color = 0
-        elif (infos[3] == "100%" or infos[3] == "100%,"): # Batterie chargée.
+        elif (level == 100): # Batterie chargée.
             icon = baticon
-            level = 100
             color = 0x00FF00
             green = 255
             red = 0
         elif (infos[2] == "Unknown,"): # État indéfini.
             # On calcule la couleur de l'icône.
-            level = int(infos[3].split("%")[0])
             if (level >= 50):
                 green = 255
                 red = 255*(100-level)*2/100
@@ -58,7 +58,6 @@ class Battery:
             icon = baticon
         elif (infos[2] == "Discharging,"): # Décharge.
             # On calcule la couleur de l'icône.
-            level = int(infos[3].split("%")[0])
             if (level >= 50):
                 green = 255
                 red = 255*(100-level)*2/100
@@ -70,7 +69,6 @@ class Battery:
             icon = baticon.rotate_simple(270)
         else: # Par déduction, charge.
             # On calcule la couleur de l'icône.
-            level = int(infos[3].split("%")[0])
             if (level >= 50):
                 green = 255
                 red = 255*(100-level)*2/100
diff --git a/devutils/laptray.py b/devutils/laptray.py
index 6376161..778ab50 100755
--- a/devutils/laptray.py
+++ b/devutils/laptray.py
@@ -1,7 +1,7 @@
 #! /usr/bin/python
 # coding: Utf-8
 
-import os, sys, gtk, gobject, commands, pynotify
+import os, sys, re, gtk, gobject, commands, pynotify
 
 cpath = sys.path[0]
 opath = cpath[:cpath.rfind("/")]
@@ -52,7 +52,7 @@ def notify(widget):
         vol = commands.getoutput("amixer get Master | cut -d'\n' -f5 | cut -d'[' -f2 | cut -d'%' -f1")
         infos += "Volume sonore : "+vol+" %\n"
     else: infos += "Volume sonore : muet\n"
-    infos += "Processeur : "+str(float(commands.getoutput("cpufreq-info -f"))/1000000.0)[0:3]+" GHz\n"
+    infos += "Processeur : %.2f GHz\n" % float(commands.getoutput("cpufreq-info -f"))/1000000
     infos += "Température : "+commands.getoutput("acpi -t | cut -d' ' -f4")+"°C"
     # Création et affichage de la notification.
     notif = pynotify.Notification(label, infos)
@@ -82,7 +82,10 @@ def update_state():
         warndown = ref["warndown"].split(",")
     else: warndown = []
     # On récupère l'état de la batterie et on teste.
-    infos = commands.getoutput("acpi -b").split()
+    infostr = commands.getoutput("acpi -b")
+    infos = infostr.split()
+    re_level = re.search(r"(\d+)%", infostr)
+    level = int(re_level.group(1)) if re_level else 0
     if (len(infos) < 3): # Pas de batterie, mais une icône est demandée.
         if (color != 0):
             newicon = baticon.rotate_simple(180)
@@ -90,7 +93,7 @@ def update_state():
             color = 0
         trayicon.set_tooltip("Pas de batterie.")
         label = "État du système :"
-    elif (infos[3] == "100%" or infos[3] == "100%,"): # Batterie chargée.
+    elif (level == 100): # Batterie chargée.
         if (color != 0x00FF00):
             charging = None
             newicon = baticon
@@ -101,7 +104,6 @@ def update_state():
         label = "Batterie chargée."
     elif (infos[2] == "Unknown,"): # État indéfini.
         # On calcule la couleur de l'icône.
-        level = int(infos[3].split("%")[0])
         if (level >= 50):
             green = 255
             red = 255*(100-level)*2/100
@@ -119,7 +121,6 @@ def update_state():
         label = "Stationnaire ("+infos[3]+")"
     elif (infos[2] == "Discharging,"): # Décharge.
         # On calcule la couleur de l'icône.
-        level = int(infos[3].split("%")[0])
         if (level >= 50):
             green = 255
             red = 255*(100-level)*2/100
@@ -139,7 +140,6 @@ def update_state():
         label = "En décharge ("+infos[3][:len(infos[3])-1]+" - "+infos[4][:5]+")"
     else: # Par déduction, charge.
         # On calcule la couleur de l'icône.
-        level = int(infos[3].split("%")[0])
         if (level >= 50):
             green = 255
             red = 255*(100-level)*2/100
diff --git a/devutils/laptray.pyc b/devutils/laptray.pyc
index d19b2c9..118400b 100644
Binary files a/devutils/laptray.pyc and b/devutils/laptray.pyc differ
diff --git a/libraries/components/fusedialogs.pyc b/libraries/components/fusedialogs.pyc
index 50104d5..40dae94 100644
Binary files a/libraries/components/fusedialogs.pyc and b/libraries/components/fusedialogs.pyc differ
diff --git a/libraries/components/images.py b/libraries/components/images.py
index 741a78e..89e9bdc 100644
--- a/libraries/components/images.py
+++ b/libraries/components/images.py
@@ -14,13 +14,9 @@ sys.path[0] = cpath
 
 __THIMG,__DEVIMG,__FOLDIMG = 1,2,3
 
-global specialfolders
 specialfolders = None
-global foldimgs
 foldimgs = {}
-global devimgs
 devimgs = {}
-global thimgs
 thimgs = {}
 
 # Charge un pixbuf à partir d'une définition.
diff --git a/libraries/components/images.pyc b/libraries/components/images.pyc
index 18cad37..d86be9f 100644
Binary files a/libraries/components/images.pyc and b/libraries/components/images.pyc differ
diff --git a/libraries/daemons/filelistener.py b/libraries/daemons/filelistener.py
index 9a7c8b0..5b6afcd 100644
--- a/libraries/daemons/filelistener.py
+++ b/libraries/daemons/filelistener.py
@@ -4,8 +4,8 @@
 import os, gobject
 
 checktime = 1000
-global mtimes ; mtimes = {}
-global listeners ; listeners = {}
+mtimes = {}
+listeners = {}
 
 # Vérifie les modifications des fichiers.
 def check_mtimes():
diff --git a/libraries/daemons/filelistener.pyc b/libraries/daemons/filelistener.pyc
index 0598c94..0f6a1bc 100644
Binary files a/libraries/daemons/filelistener.pyc and b/libraries/daemons/filelistener.pyc differ
diff --git a/libraries/daemons/mtman.pyc b/libraries/daemons/mtman.pyc
index f41c885..6840b36 100644
Binary files a/libraries/daemons/mtman.pyc and b/libraries/daemons/mtman.pyc differ
diff --git a/libraries/daemons/settings.py b/libraries/daemons/settings.py
index 9bd9f0a..cf2d252 100644
--- a/libraries/daemons/settings.py
+++ b/libraries/daemons/settings.py
@@ -2,16 +2,11 @@
 # coding: Utf-8
 
 import os, ConfigParser
-home = os.path.expanduser('~')
-path = home+"/.config/touhy/"
+path = os.path.expanduser("~/.config/touhy/")
 
-global fullpathes
 fullpathes = {}
-global confdicts
 confdicts = {}
-global listeners
 listeners = {}
-global mtimes
 mtimes = {}
 
 # Ce module est une surcouche du filelistener.
diff --git a/libraries/daemons/settings.pyc b/libraries/daemons/settings.pyc
index 959b250..0e96752 100644
Binary files a/libraries/daemons/settings.pyc and b/libraries/daemons/settings.pyc differ
diff --git a/touhy b/touhy
index a5871d7..a5ae034 100755
--- a/touhy
+++ b/touhy
@@ -30,23 +30,23 @@ if (rewrite): settings.save(cfile)
 # Réagit au changement de configuration.
 def manage(filename, section, modlist):
     # Pour tous les modules repérés…
-    for module in modlist.keys():
+    for module in modlist:
         # Si le module est présent, est-il actif ?
-        if (valtrue.__contains__(modlist[module])):
-            # Oui, est-ce qu'on l'a déjà activé ?
-            if (not loaded_modules.__contains__(module)):
-                # Non, on active maintenant.
-                loaded_modules.append(module)
-                __import__(module).start()
-        # Sinon, a-t-il été préalablement activé ?
-        elif (loaded_modules.__contains__(module)):
+        # Si oui, est-ce qu'on l'a déjà activé ?
+        if modlist[module] in valtrue and module not in loaded_modules:
+            # Non, on active maintenant.
+            loaded_modules.append(module)
+            __import__(module).start()
+        # Si le module est présent, est-il actif ?
+        # Si non, a-t-il été préalablement activé ?
+        if not modlist[module] in valtrue and module in loaded_modules:
             # Oui, on désactive maintenant.
             loaded_modules.remove(module)
             __import__(module).stop()
     # Pour les modules déjà référencés…
     for module in loaded_modules:
         # Ont-ils été oubliés entre temps ?
-        if (not modlist.has_key(module)):
+        if module not in modlist:
             # Oui, donc on les arrête.
             loaded_modules.remove(module)
             __import__(module).stop()
@@ -67,7 +67,14 @@ signal.signal(signal.SIGINT, stopall)
 
 # Si rien de lancé, on règle.
 if (len(loaded_modules) == 0):
-    os.system(sys.path[0]+"/settings/modules &")
+    pid = os.fork()
+    if pid:
+        os.waitpid(pid, 0)
+    else:
+        configgui = os.path.join(sys.path[0], "settings/modules")
+        os.execl(configgui, configgui)
+    ## ou plus simple :
+    #os.popen(os.path.join(sys.path[0], "settings/modules")).close()
 
 # c'est bon.
 gtk.main()
diff --git a/wallman/wallpainter.py b/wallman/wallpainter.py
index ceb409b..38e2976 100755
--- a/wallman/wallpainter.py
+++ b/wallman/wallpainter.py
@@ -14,13 +14,10 @@ active = True
 deskwin = None
 deskcomp = None
 
-global pixid
-pixid = 0L
+pixid = 0
 
-global wallnum
 wallnum = 0
 
-global checkby
 checkby = {}
 
 # Vérification de la configuration.
diff --git a/wallman/wallpainter.pyc b/wallman/wallpainter.pyc
index d98090f..19b0aa9 100644
Binary files a/wallman/wallpainter.pyc and b/wallman/wallpainter.pyc differ

Ou sinon, pour lancer touhy/settings/modules, on pourrait l’importer, non ?

Dernière modification par Πυλάδης (Le 21/08/2011, à 17:07)

Elzen · Le 21/08/2011, à 17:48

Πυλάδης a écrit :

Ah, et j’ai changé quelques trucs dans le code de Touhy, je veux bien savoir ce que tu en penses :

J'en pense qu'il faudra que je regarde ça un peu plus dans le détail un de ces jours

Pour les global partout, ça vient d'avant que je ne découvre les méthodes setdefault et pop d'un dictionnaire : je ne voyais pas d'autres choix que de faire « dict[clef] = valeur » et « del(dict[clef]) », ce qui nécessitait que la variable soit globale pour être prit en compte en dehors de la méthode effectuant l'opération.

Ah, par contre, pour celle concernant le pixid dans le wallpainter, je crois qu'il faut le laisser : je l'utilise par soucis d'optimisation, pour vérifier à chaque fois que je demande au système quel est le fond d'écran de pseudo-transparence si celui-ci a changé ou pas, histoire de ne refaire le traitement que s'il a changé (et j'ai mis un 0L comme valeur par défaut au lieu d'un 0, parce que la méthode utilisée me renvoie un long, donc j'trouvais ça plus clair).
Si la variable n'est plus globale, elle n'est modifiée qu'en interne à la fonction, et donc, à chaque fois que tu relances la méthode en question (ce qui se fait pour des raisons autres que le fait que la pseudo-transparence ait changé), tu compares la valeur actuelle à 0, et donc tu refais tout le traitement. Me semble-t-il.

Pour tout ce qui concerne le module re, je ne le connais pas du tout, donc j'peux pas trop juger, mais j'te fais confiance

Pour la syntaxe value in valtrue plutôt que valtrue.__contains__(value), ç'pareil que pour le global : j'ne m'étais pas rendu compte que ça existait, donc j'n'utilisais pas. Mais ça me paraissait effectivement bizarre de devoir utiliser une méthode avec des __ dans le nom ^^
J'crois avoir commencé à corriger, petit à petit.

Pour le lancement plus « propre » de l'exécutable, c'est probablement mieux, mais il faudrait voir à pas mal d'autres endroit que celui-là, j'utilise du os.system() assez souvent.

Pour le fait de d'abord récupérer le résultat d'une commande dans une chaîne de caractère, puis de spliter ladite chaîne de caractère plutôt que de faire les deux opérations en même temps, y a une raison particulière ? J'ai tendance à penser que si on peut se passer d'une variable sans paumer en lisibilité ni refaire quinze fois les mêmes appels, autant le faire.
Ah, ou alors c'est parce que tu as besoin de la chaîne de caractère intacte pour la passer à re derrière ? Dans ce cas,-là, c'est plutôt le split(), s'il ne sert plus, qu'on pourrait ne calculer que là où on a besoin de sa longueur, non ? Enfin, il faut que je relise le code un peu plus en détail, quoi.

Πυλάδης a écrit :

Ou sinon, pour lancer touhy/settings/modules, on pourrait l’importer, non ?

Bah en fait, j'y avais pensé, et puis j'ai trouvé plus intéressant de le laisser comme exécutable à part pour deux raisons :
– d'abord, ça gère l'activation des modules et compagnie. C'est le genre de choses pour lequel, à titre personnel, j'préfère que ça attende que j'ai cliqué sur le bouton « valider » pour que ça change (si c'était importé, les modifs se feraient en dynamique, juste au clic sur une case à cocher, ce qui serait un peu lourd.
– et puis l'outil de config en question m'a déjà planté entre les mains sans raison apparente, et je n'ai encore rien pu faire pour corriger ça vu que je ne sais pas du tout d'où ça vient. Donc j'ai tendance à préférer que, si ça plante, ça ne fasse pas planter Touhy lui-même.

tshirtman · Le 21/08/2011, à 18:11

https://github.com/tshirtman/snakenest

bon, c'est vraiment pas grand chose, mais c'est un début de semblant de forum… c'est testable là

http://pub.tshirtman.fr:5000/login

admin/password

Pylades · Le 21/08/2011, à 21:12

ArkSeth a écrit :

Pour les global partout, ça vient d'avant que je ne découvre les méthodes setdefault et pop d'un dictionnaire : je ne voyais pas d'autres choix que de faire « dict[clef] = valeur » et « del(dict[clef]) », ce qui nécessitait que la variable soit globale pour être prit en compte en dehors de la méthode effectuant l'opération.
Ah, par contre, pour celle concernant le pixid dans le wallpainter, je crois qu'il faut le laisser : je l'utilise par soucis d'optimisation, pour vérifier à chaque fois que je demande au système quel est le fond d'écran de pseudo-transparence si celui-ci a changé ou pas, histoire de ne refaire le traitement que s'il a changé (et j'ai mis un 0L comme valeur par défaut au lieu d'un 0, parce que la méthode utilisée me renvoie un long, donc j'trouvais ça plus clair).
Si la variable n'est plus globale, elle n'est modifiée qu'en interne à la fonction, et donc, à chaque fois que tu relances la méthode en question (ce qui se fait pour des raisons autres que le fait que la pseudo-transparence ait changé), tu compares la valeur actuelle à 0, et donc tu refais tout le traitement. Me semble-t-il.

Ben en fait, ça sert à rien de mettre global dans l’espace global de ton script, ça Python est bien capable de s’en rendre compte lui-même. C’est à l’intérieur de tes fonctions qu’il faut déclarer le nom en global. J’ai juste retiré les lignes qui ne servaient à rien. Chez moi Touhy continue de fonctionner, hein. ^^

Pour l’histoire du long, Python gère tout ça lui-même en interne, donc le codeur n’a pas à se préoccuper de ça ; et de toutes façons la marche des choses c’est que ce type disparaisse, d’ailleurs il n’existe plus en Python 3 qui renvoie une erreur de syntaxe sur ce genre de ligne, donc je pense que c’est une raison suffisante pour s’en passer.

ArkSeth a écrit :

Pour tout ce qui concerne le module re, je ne le connais pas du tout, donc j'peux pas trop juger, mais j'te fais confiance

Ben en fait, j’ai juste commencé à proprer le traitement des sorties parce qu’avant ça pouvait faire n’importe quoi ; utiliser une regex c’est mieux que faire confiance au nombre d’espaces. En plus ça économise des lignes de code, et ça en économisera plus quand j’aurai fini. Mais bon, de toutes façons ça serait bien mieux de trouver les bibliothèques qui vont bien plutôt que de parser de la sortie standard… donc j’espère que ce n’est que temporaire. ^^

ArkSeth a écrit :

Pour le lancement plus « propre » de l'exécutable, c'est probablement mieux, mais il faudrait voir à pas mal d'autres endroit que celui-là, j'utilise du os.system() assez souvent.

Ouais, enfin là c’est le « & » qui m’avait choqué, ajouté au fait que tu connaisses le chemin de l’exécutable. Mais bon, l’usage de os.system ne me gène pas plus que ça dans Touhy.

ArkSeth a écrit :

Pour le fait de d'abord récupérer le résultat d'une commande dans une chaîne de caractère, puis de spliter ladite chaîne de caractère plutôt que de faire les deux opérations en même temps, y a une raison particulière ? J'ai tendance à penser que si on peut se passer d'une variable sans paumer en lisibilité ni refaire quinze fois les mêmes appels, autant le faire.
Ah, ou alors c'est parce que tu as besoin de la chaîne de caractère intacte pour la passer à re derrière ? Dans ce cas,-là, c'est plutôt le split(), s'il ne sert plus, qu'on pourrait ne calculer que là où on a besoin de sa longueur, non ? Enfin, il faut que je relise le code un peu plus en détail, quoi.

Ouais, il me faut la chaîne pour la passer à re. Et je ne peux pas virer l’appel à split, vu que tu l’utilises à côté. En fait c’est du code de transition, donc c’est un peu moche là, mais ça va s’arranger.
Sinon utiliser des variable intermédiaires ça peut être bien pour éviter de se retrouver avec des lignes über longues, surtout en Python où t’es pas à ça près pour les perfs.

ArkSeth a écrit :

Πυλάδης a écrit :
Ou sinon, pour lancer touhy/settings/modules, on pourrait l’importer, non ?
Bah en fait, j'y avais pensé, et puis j'ai trouvé plus intéressant de le laisser comme exécutable à part pour deux raisons :
– d'abord, ça gère l'activation des modules et compagnie. C'est le genre de choses pour lequel, à titre personnel, j'préfère que ça attende que j'ai cliqué sur le bouton « valider » pour que ça change (si c'était importé, les modifs se feraient en dynamique, juste au clic sur une case à cocher, ce qui serait un peu lourd.

Pas grave, puisqu’à l’endroit depuis lequel tu l’exécutes, Touhy n’est pas encore vraiment lancé.

ArkSeth a écrit :

– et puis l'outil de config en question m'a déjà planté entre les mains sans raison apparente, et je n'ai encore rien pu faire pour corriger ça vu que je ne sais pas du tout d'où ça vient. Donc j'ai tendance à préférer que, si ça plante, ça ne fasse pas planter Touhy lui-même.

Idem, on s’en fout puisque Touhy n’est pas encore vraiment lancé (et c’est même mieux, ça évite de lancer Touhy alors que la conf n’a pas été faite).

Sinon, une petite remarque : au lieu de faire path1 + path2, c’est bien de faire os.path.join(path1, path2).

Dernière modification par Πυλάδης (Le 21/08/2011, à 22:17)

Elzen · Le 21/08/2011, à 21:45

Hmm, c'est moi où il y a, surtout venant de toi, un taux d'erreurs ce/se relativement élevé dans ce post ? Et puis des er aussi ont eu du mal

Πυλάδης a écrit :

Ouais, enfin là c’est le « & » qui m’avait choqué, ajouté au fait que tu connaisses le chemin de l’exécutable. Mais bon, l’usage de os.system ne me gène pas plus que ça dans Touhy.

Bah j'connais le chemin dans la mesure où c'est dans le répertoire de Touhy, c'est sûr qu'en version proprement installée, il faudrait faire différemment ^^

Πυλάδης a écrit :

En fait c’est du code de transition, donc c’est un peu moche là, mais ça va s’arrange.

Ouais, en effet. D'ailleurs, j'suis d'accord sur le fait qu'il faudrait que je trouve les bibliothèques python qui vont bien pour faire ça en interne plutôt que de faire appel à des commandes externes moches. C'est ce que j'ai partiellement commencé à faire (genre pour la gestion des périphériques), mais je manque encore de connaissances sur les biblis systèmes dispos (d'autant que j'ai aussi un lourd passé de bidouilleur à me faire des scripts autour de tout et de n'importe quoi)

Πυλάδης a écrit :

Sinon utiliser des variable intermédiaires ça peut être bien pour éviter de se retrouver avec des lignes über longues, surtout en Python où t’es pas à ça près pour les perfs.

Ouais, c'est sûr que j'hésite pas quand il s'agit de faire tenir les lignes qui sont « dans un if dans un for dans un if dans une fonction » sur 80 caractères ^^

Πυλάδης a écrit :

Sinon, une petite remarque : au lieu de faire path1 + path2, c’est bien de faire os.path.join(path1, path2).

Pas faux. En plus, comme j'ai été temporairement découragé par gtkmozembed, j'suis plutôt en train de m'occuper (par toutes petites touches) du navigateur de fichiers, donc j'vais tenter d'y penser

Pylades · Le 21/08/2011, à 21:52

ArkSeth a écrit :

Hmm, c'est moi où il y a, surtout venant de toi, un taux d'erreurs ce/se relativement élevé dans ce post ?

Je n’en vois qu’une…

ArkSeth a écrit :

Et puis des er aussi ont eu du mal

Je ne vois pas…

Elzen · Le 21/08/2011, à 22:04

Sous la première quote :
– « c'est à l'intérieur des fonctions qu'il faut déclarer », je pense (ça en fait pas partie, mais au passage).
– « une erreur de syntaxe sur ce genre de ligne »
– Au passage aussi, l'expression « de toute façon » est censée s'écrire au singulier, en théorie (on retrouve la même un peu plus bas).

Sous la quatrième quote :
– « mais ça va s'arranger ».

Sous l'avant-dernière :
– « depuis lequel tu l'exécutes » (idem, au passage aussi).

Et sous la dernière :
– « Et c'est même mieux, ça évide de lancer ».

Bizarre, une erreur se/ce, j'étais persuadé d'en avoir vu au moins une deuxième, mais je la retrouve pas…
Mais bon, même si ça ne fait pas beaucoup de fautes au total, venant de toi, ça m'étonne

Dernière modification par ArkSeth (Le 21/08/2011, à 22:06)

Pylades · Le 21/08/2011, à 22:13

ArkSeth a écrit :

– « c'est à l'intérieur des fonctions qu'il faut déclarer », je pense (ça en fait pas partie, mais au passage).

Je l’avais vue.

ArkSeth a écrit :

– « une erreur de syntaxe sur ce genre de ligne »

Je l’avais vue.

ArkSeth a écrit :

– Au passage aussi, l'expression « de toute façon » est censée s'écrire au singulier, en théorie (on retrouve la même un peu plus bas).

Tu veux que j’invoque 34709 ?

ArkSeth a écrit :

– « mais ça va s'arranger ».

Pas vue…

ArkSeth a écrit :

– « depuis lequel tu l'exécutes » (idem, au passage aussi).

Pas vue…

ArkSeth a écrit :

– « Et c'est même mieux, ça évide de lancer ».

Pas vues…

Bon, merci, je vais corriger ça…

ArkSeth a écrit :

Bizarre, une erreur se/ce, j'étais persuadé d'en avoir vu au moins une deuxième, mais je la retrouve pas…
Mais bon, même si ça ne fait pas beaucoup de fautes au total, venant de toi, ça m'étonne

Ouais, c’est bon, on a bien vu que tu jouais ton grammar nazi.

↓↓ Édit : qu’est-ce que je disais ? ↓↓

Dernière modification par Πυλάδης (Le 21/08/2011, à 22:37)

Elzen · Le 21/08/2011, à 22:18

Pour la dernière, c'est pas vues au pluriel, j'pense, vu qu'il y en a deux

Et j'sais pas, c'est fun de relire les gens. Comme après une dictée. Ça me manque, les dictées.

samυncle · Le 21/08/2011, à 22:46

.

HP · Le 21/08/2011, à 22:54

def iif(condition, v_true, v_false):
    return (condition and (v_true,) or (v_false,))[0]

The Uploader · Le 21/08/2011, à 22:58

C'est quoi l'intérêt de la fonction ?

HP · Le 21/08/2011, à 22:59

Je te laisse deviner… sinon, est-il obligatoire qu'une fonction ai un intérêt très profond ?

The Uploader · Le 21/08/2011, à 23:11

Non, j'arrive pas trop à deviner à part qu'on dirait que tu remplace '&&' par ton 'iif'..?

HP a écrit :

sinon, est-il obligatoire qu'une fonction ai un intérêt très profond ?

Tu fais des fonctions sans intérêt ?
Blague à part, si ce que je devine est juste, j'vois pas le gain de ligne/char de code. Là, c'est plutôt négatif.

HP · Le 21/08/2011, à 23:52

The Uploader a écrit :

Blague à part, si ce que je devine est juste, j'vois pas le gain de ligne/char de code. Là, c'est plutôt négatif.

Je pense que tu devines faux… et pourtant il suffit de faire une simple recherche…
Le gain, à mon sens, existe ; ne serait-ce que pour la syntaxe plus légère.

The Uploader a écrit :

Tu fais des fonctions sans intérêt ?

Comme tout le monde .

The Uploader · Le 22/08/2011, à 00:04

HP a écrit :

The Uploader a écrit :
Blague à part, si ce que je devine est juste, j'vois pas le gain de ligne/char de code. Là, c'est plutôt négatif.
Je pense que tu devines faux… et pourtant il suffit de faire une simple recherche…

Ah mais t'as dit de deviner, Google c'est de la triche dans ce cas! ^^
'fin ouais c'est pas '&&' en fait, par contre je n'ai jamais eu à utiliser le 'iif' de VB, donc j'ai un peu de mal à voir les cas d'utilisation. Cependant, l'intérêt n'est plus nul.

HP a écrit :

The Uploader a écrit :
Tu fais des fonctions sans intérêt ?
Comme tout le monde .

Non. Même une procédure/méthode "haut niveau" qui semble être redondante avec l'usage des fonctions "bas niveau" auquelles elle fait appel a au moins le mérite de cacher la complexité, et de rendre plus lisible le code appelant. Même un 'one-liner' peut être utile, ça dépend de son contenu.

HP · Le 22/08/2011, à 00:11

C'était, donc, simplement une fonction destinée à imiter un opérateur ternaire.

The Uploader · Le 22/08/2011, à 00:13

L'opérateur ternaire de Python est pas plus lisible ? et ce : directement.

(un opérateur ternaire est bien mal caché dans la phrase ci dessus)

Sir Na Kraïou · Le 22/08/2011, à 01:03

Æ.

Dernière modification par na kraïou (Le 22/08/2011, à 02:02)

nesthib · Le 22/08/2011, à 02:02

plop

Pylades · Le 22/08/2011, à 03:50

ArkSeth a écrit :

Πυλάδης a écrit :
Rah ! À pas grand chose près, je n’ai pas pu la récupérer.
'Ç'qui se passe ? J'peux faire quelque chose ?

Nan, je disais juste que t’as collé le lien juste après que je n’aie plus accès à Internet. ^^

ArkSeth a écrit :

Πυλάδης a écrit :
[elzterm]
* quand nouveau fichier de conf : nécessité d’indiquer « raws » sinon crash
* appui sur <CR> dans le champ d’édition du label ne valide pas
[touhy]
* hideux quand dans autostart.sh sans sleep ; openbox buggé si pas de subshell
Pas tout compris, tu peux réexpliquer ça en français ?

Pour le coup du autostart.sh, je crois que t’as compris.
Pour Elzterm, quand tu le lance sans fichier de conf, ça ne fonctionne pas : t’es obligé d’indiquer la valeur de « raws » pour qu’il puisse démarrer…
Sinon, quand tu édites le label d’un onglet, tu ne peux pas juste valider en appuyant sur la touche « entrée », t’es obligé de sélectionner le bouton de validation est c’est un peu gênant. Donc pas gravissime mais c’est bien de le noter.

ArkSeth a écrit :

Πυλάδης a écrit :
BeautifulSoup…
Plaît-il ?

C’est une bibliothèque Python pour parser du {,X}HTML, ça fonctionne bien et c’est utilisé dans le code du compteur.

ArkSeth a écrit :

Le dirs en question, j'men sers pas, moi, si ?

Euh… j’ai un peu oublié à quoi je faisais référence, là… mais je tâcherai de m’en souvenir…

Dernière modification par Πυλάδης (Le 22/08/2011, à 04:13)

Compteur du TdCCT · Le 22/08/2011, à 06:42

Scores totaux, depuis le début :

1) 4130    nesthib
2) 3527    samuncle
3) 3519    Πυλάδης
4) 2537    Кຼزດ
5) 2011    cm-t
6) 1800+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 1750    na kraïou
8) 905    helly
9) 877    \\Ouranos//
10) 795    tshirtman
11) 659    gnuuat
12) 565    Lagierl
13) 448    Rolinh
14) 444    The Uploader
15) 428    nathéo
16) 271    Kanor
17) 202    :!pakman
18) 196    Askelon
19) 121    ǤƦƯƝƬ
20) 116    HP
21) 103    kamui57
22) 93    petifrancais
23) 78    edge_one
23) 78    pierguiard
25) 70    gulp
26) 45    Le Rouge
27) 42    sakul
28) 38    xapantu
29) 37    ilagas
30) 35    pfranco
31) 30    keny
31) 30    Atem18
33) 29    Steap
34) 26    gustare
34) 26    d10g3n
36) 25    GentooUser
36) 25    Morgiver
38) 24    ไ୦บเઢ'
39) 20    CROWD
40) 18    Ph3nix_
41) 16    kouskous
42) 15    timsy
43) 12    stratoboy
43) 12    sailing
45) 11    alexises
45) 11    Crocoii
47) 10    Toineo
47) 10    NutMotion
47) 10    pseudovingtcinqcaracteres
47) 10    pfriedZ
47) 10    CasseTaTele
47) 10    Zeibux
47) 10    THS`
47) 10    golgoth42
47) 10    ꙳♒⏅⚓ ЅаίԼίՈԶ ⚓⏅♒꙳
47) 10    Ras'
57) 8    Mornagest
58) 7    Vista
59) 6    ubuntlin
59) 6    asma.geek
59) 6    sweetly
62) 5    tendances-tdct
62) 5    kinouchou
64) 4    danychou56
64) 4    Neros
64) 4    Biaise
64) 4    totoflute
64) 4    pinballyoda ㋛
64) 4    NLS le pingouin
64) 4    ceric
64) 4    Dice-Man
64) 4    Pylade
73) 3    Revan26914
73) 3    raspouillas
73) 3    DaveNull
73) 3    DnS
77) 2    SoJaS
78) 1    geenux
78) 1    ArzhurBZH
78) 1    monsieurweller

Répartition Posts/heure

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2101 Le 21/08/2011, à 15:56

Re : /* Topic des codeurs couche-tard [5] */

#2102 Le 21/08/2011, à 16:06

Re : /* Topic des codeurs couche-tard [5] */

#2103 Le 21/08/2011, à 16:37

Re : /* Topic des codeurs couche-tard [5] */

#2104 Le 21/08/2011, à 17:07

Re : /* Topic des codeurs couche-tard [5] */

#2105 Le 21/08/2011, à 17:48

Re : /* Topic des codeurs couche-tard [5] */

#2106 Le 21/08/2011, à 18:11

Re : /* Topic des codeurs couche-tard [5] */

#2107 Le 21/08/2011, à 21:12

Re : /* Topic des codeurs couche-tard [5] */

#2108 Le 21/08/2011, à 21:45

Re : /* Topic des codeurs couche-tard [5] */

#2109 Le 21/08/2011, à 21:52

Re : /* Topic des codeurs couche-tard [5] */

#2110 Le 21/08/2011, à 22:04

Re : /* Topic des codeurs couche-tard [5] */

#2111 Le 21/08/2011, à 22:13

Re : /* Topic des codeurs couche-tard [5] */

#2112 Le 21/08/2011, à 22:18

Re : /* Topic des codeurs couche-tard [5] */

#2113 Le 21/08/2011, à 22:46

Re : /* Topic des codeurs couche-tard [5] */

#2114 Le 21/08/2011, à 22:54

Re : /* Topic des codeurs couche-tard [5] */

#2115 Le 21/08/2011, à 22:58

Re : /* Topic des codeurs couche-tard [5] */

#2116 Le 21/08/2011, à 22:59

Re : /* Topic des codeurs couche-tard [5] */

#2117 Le 21/08/2011, à 23:11

Re : /* Topic des codeurs couche-tard [5] */

#2118 Le 21/08/2011, à 23:52

Re : /* Topic des codeurs couche-tard [5] */

#2119 Le 22/08/2011, à 00:04

Re : /* Topic des codeurs couche-tard [5] */

#2120 Le 22/08/2011, à 00:11

Re : /* Topic des codeurs couche-tard [5] */

#2121 Le 22/08/2011, à 00:13

Re : /* Topic des codeurs couche-tard [5] */

#2122 Le 22/08/2011, à 01:03

Re : /* Topic des codeurs couche-tard [5] */

#2123 Le 22/08/2011, à 02:02

Re : /* Topic des codeurs couche-tard [5] */

#2124 Le 22/08/2011, à 03:50

Re : /* Topic des codeurs couche-tard [5] */

#2125 Le 22/08/2011, à 06:42

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums