Aeris a écrit 444 commentaires

Mettre à jour régulièrement ses programmes n'est pas incompatible avec ne pas utiliser sid ou experimental.

La mise-à-jour régulière, c'est pour appliquer les patches de sécu et fixer les gros bugs méchants, histoire d'avoir un minimum de sécurité. Si on peut rester sur les mêmes versions majeures des softs, c'est même d'autant mieux.
L'utilisation de sid ou experimental aurait même l'effet inverse, en mettant en place des versions de softs non éprouvées remplies de failles et de bugs non fixés.

Sans parler de la question habituelle : a-t-on vraiment besoin de la fonctionnalité de la mort-qui-tue pas testée de la dernière version pas stable ou est-ce que c'est de la kikoololerie bling-bling et qu'on peut très bien s'en passer ?
J'ai jamais vraiment rencontré de cas crédible et défendable du 1er cas… Par contre le 2nd, j'en vois pléthore tous les jours, et généralement ça se finit assez mal =)

Je ne vois pas quel utilisateur normalement constitué a besoin de sid et encore moins d'expérimental…
Même moi en tant que dev confirmé, je dépasse rarement testing, alors…

Et ma dernière install de KDE date d'il y a à peine quelques semaines, sans aucun soucis notable.

Encore une fois, mauvais utilisateur, changer utilisateur =)

J'ai du mal à comprendre ton désarroi…

Je suis sous KDE 4.8.4 (testing/unstable) depuis des lustres, en full UTF8 depuis maintenant plus de 2 ans.
J'ai des cartes graphiques à la con (NVidia) et des cartes sons encore plus à la con (Creative X-Fi).
J'utilise couramment LibreOffice et Icedove, Scribus de temps en temps.
Je manipule des documents qui proviennent d'environnement Windows avec tout ce que j'ai pu voir comme nommage débile de fichier, à grand coup d'accents, en ISO ou UTF.

Et je n'ai JAMAIS (je dis bien JAMAIS) eu le moindre des soucis desquels tu parles, que ça soit l'encodage UTF8, l'absence de son ou la souris sauteuse…
Et d'ailleurs, je ne vois même pas ce que KDE vient faire là-dedans (surtout pour LibreOffice et Icedove qui ne dépendent même pas de lui), si les fichiers n'arrivaient pas à être lu, ça n'a qu'une chance infime de provenir du WM, mais toutes les chances d'être à cause du filesystem ou du kernel.

Avant de commencer à taper sur tous les logiciels les uns après les autres (LibreOffice/Icedove, maintenant KDE…), faudrait peut-être remettre en cause l'autre bout de la chaîne, à savoir l'utilisateur.
Comme on dit toujours « mauvais utilisateur, changer utilisateur » =)

Hello !
Je suis dans la même situation que toi, TMS depuis 1 an et du coup je me suis tout re-équiper aussi, TM et trackball pour ma part.
Par contre, je tient à apporter une précision à mon avis importante et qui a eu de graves conséquences pour moi : consultez un médecin avant de changer votre matériel, en tout cas si ce n'est pas juste un changement « de confort » et que vous avez déjà des TMS et/ou des douleurs !

Dans mon cas, j'avais une douleur au poignet, type syndrôme canal carpien.
Suivant les conseils trouvés sur le net, passage au TM, qui a déjà pas mal amélioré ma situation.
Vu que tout le monde était aussi très content de sa souris verticale et que mon expérience avec le TM était très concluante, j'ai aussi investi dans une souris verticale Evoluent.

Et là ce fut le drame… En fait je ne souffrais pas du syndrôme du canal carpien, qui touche le nerf central du poignet et rejoint le pouce (dans ce cas la souris verticale est vraiment un plus), mais du canal ulnaire, qui lui passe sur le côté de la main et rejoint l'auriculaire.
Bilan des courses, la souris verticale n'a fait qu'empirer ma situation, le nerf en question étant constamment en contact avec le bureau et supportant la totalité du poids de la main !
J'avais moins mal lors de l'utilisation de ma souris (apparement parce que le nerf était toujours sous pression), mais le nerf en question était juste en train de s'user à vitesse grand V et j'avais de plus en plus mal en dehors de la bureautique !
J'ai échappé à l'intervention chirurgicale de justesse, 7 jours d'ITT après 1 mois d'utilisation seulement, et j'ai changé pour un trackball.

En plus de m'avoir coûter une blinde inutilement, décider de changer de matériel sans consulter un médecin alors qu'on a déjà des douleurs, c'est pas très conseillé et ça peut même empirer la situation. Allez consulter si vous avez des douleurs, et ne prenez pas de décisions sans l'avis d'un médecin !

Surtout quand on voit le débat qui en a suivi =)
C'est qu'elles sont loin d'être triviales, ces 3 lignes !

Ça tombe bien, ce ctrl+espace affiche aussi la javadoc, le monde est bien fait.

Elle arrive après la bataille, la javadoc…
Le 1er ctrl+espace, elle t'affiche toutes les méthodes et attributs disponibles d'abord, avec le typage de chaque paramètre et le type de retour. C'est ça qui me file le plus gros coup de pouce.
La javadoc sur le 2nd ctrl+espace, c'est le cadeau dans le paquet de céréales, elle ne me sert que très très rarement, et ne fait que confirmer que j'ai fait le bon choix =)

Enfin, j'aimerais bien voir ta tronche si la bibliothèque standard de Java était livrée sans doc, sous prétexte qu'il suffit de lire le code.

Et bien bizarrement, je consulte bien moins voire quasiment pas les javadoc (sinon à l'apprentissage d'une librairie) que je ne consulte les docstring python !
Généralement, un ctrl+espace sous Eclipse me met à dispo tout ce que j'ai besoin, sans avoir besoin de la javadoc.

Au contraire, même après avoir utilisé plusieurs centaines de fois une méthode en python, j'en suis toujours à me poser des questions dessus voire même à trouver quoi appeler et comment le jour où j'en ai besoin…

La fonction, à la base, elle prend une liste, pas n'importe nawak.

Pk elle prend une liste ? Un tuple est tout aussi autorisé, comme tout ce qui peut être itérable. On fait du python ou pas à la fin ?

Ben déjà en Java au final, je laisserais le mec me gérer toute la merde d'ouverture et cie, et je prendrais uniquement un InputStream en paramètre.
Ça permet même d'être encore plus générique, en reportant sur l'utilisateur le choix de m'envoyer ce qu'il veut, que ça soit un FileInputStream, un MemoryStream ou même un SocketStream !

Si des softs sont mal codé, c'est la faute au dev, pas du langage et son de typage dynamique.

Ou que le langage est trop permissif =)
Ou alors que le bon développeur Python n'existe tout simplement pas, vu la réputation des gus qui taffent sur les projets sus-nommés.

Non, parce qu'on va parcourir 2× l'itérable dans le cas où l'objet est réellement itérable.

On revient à ce que je disais, tu codes en python comme tu codes en java: Tu veux savoir si c'est du type iterable avant de travailler dessus.
En python on s'en fout : on essaye et si ça passe pas c'est que c'est pas un iterable.

Raté, c'est pas mon code, mais le code d'exemple que j'ai donné est issu de très grosses librairies python mondialement utilisées. Rhodecode, DJango, Pylon, et même la lib standard Python si mes souvenirs sont exacts !!!…
On est donc d'accord, Python code comme en Java, malgré le duck-typing et le typage dynamique…

Ça ne change strictement rien.
Et j'ai pas demander de faire une boucle sur un iterable, juste de tester si ça l'est (principe du duck-typing), en plus de trouver une solution pythonesque à une pythonerie très courante consistant à « caster » en liste un argument simple.

En gros plus un truc dans le goût:

def _do_stuff(param):
  blabla
  blabla

def do_stuff(param):
  if not is_iterable(param):
    param= [ param ]
        _do_stuff(param)

Je l'ai vu très souvent en python ça, y compris dans DJango, Rhodecode et d'autres trucs Python, mais tous sont soit buggés (is_iterable pas vraiment is_iterable, cas des generateurs infinis, cas des basestrings), soit limite le duck-typing (is_iterable = list et tuple, point barre…).

Un générateur peut être infini.
Et donc ton code ne jamais se finir, alors que le do_stuff lui pouvait se finir sans ton test d'iterable (condition d'arrêt, utilisation de seulement certaines valeurs, etc).

def foo():
  while True:
    yield 1

function(foo())

Je m'y attendais à celle-là =)

def foo():
   yield 1

function(foo())

Je vais attendre un bail…
Same player shoot again ?

Je parlais dans le cadre du Java.

Clairement dans python, je ne suis pas capable de faire tout ça. Du coup je dois documenter, doc qui va devenir obsolète avec le temps, donc conduire à des erreurs, de la perte de temps, etc.
En plus la doc python n'est généralement pas suffisante pour coder les couches appelantes, et il faudra aller lire le code de toute façon, doc ou pas doc…

En même temps niveau code pythonesque, encore trouvé dans le code de DJango aujourd'hui

241         if not isinstance(result, (list, tuple)):                                                                                        
242             result = [result]

On est clairement dans le cas « Ah wé mais merde, les mecs me passent aussi un singleton et pas une liste en paramètre, aller, ça va passer quand même… ».
Généralement, c'est aussi pour se simplifier la vie et pouvoir appeler du foo(toto) au lieu de foo([toto]).

Soit on fait du vrai duck-typing, et donc on arrête de se limiter qu'au list et tuple et on prend aussi du seq, du generator et tout ce qui est itérable. Et je met au défi quiconque ici de me donner le code python qui permettra de faire ça :þ
Soit on fait du vrai typing, et donc on arrête le python.

En quoi est-ce une perle ?
À partir du moment où tu as la nécessité de documenter ton code parce qu'il n'est pas compréhensible, pourquoi ne pas plutôt le refactorer pour le rendre justement compréhensible sans doc ?
Connaissant la propension de la doc à devenir fausse avec le temps, je préfère un code auto-porteur compréhensible sans doc qu'un code pas compréhensible avec une doc fausse.
Et un code compréhensible documenté, du coup c'est de la perte de temps et du bruit…

Après oui, je vais quand même documenter les morceaux vraiment « impropifiables », type les algos bas niveaux ou les trucs vraiment mathématiques.

Et oui, tout le monde est au courant =)

Ah non, moi je lit 3 lignes de python, pas 8. Si tu comptes la docstring python faut que tu comptes aussi la javadoc pour être cohérent.

Non, car la javadoc est facultative pour le développement (elle est même presque complètement interdite dans mes équipes de dev, un code qui a besoin d'une doc est un code qui doit être réécrit !), alors que la docstring python est obligatoire sous peine de ne pas savoir quoi passer en paramètre et ce qui est retourné !
La javadoc est vraiment du domaine de la documentation, alors que la docstring est du domaine du développement.

Et trouve moi un seul mec qui va m'écrire ce code java du 1er coup…

Je te l'accorde, mais je pense que le niveau minimal en Java qui conduira à écrire ce code naturellement est bien plus faible que celui de Python.
J'aurais même tendance à dire que la culture Java-iste a tendance à inculquer ce genre de bonne pratique assez tôt, ce qui n'est pas le cas de Python où c'est plutôt généralement du DIY.
Je ne suis même pas sûr que la personne qui déclare ici avoir 20 ans d'expérience Python l'aurait écrit comme ça…

Cela fait toujours plus que ton exemple java, mais cela me permet d'utiliser cette méthode sur tout type pouvant s'itérer, que ce soit un fichier, un tableau excel, une main (pour lire les ligne de la main… bon ok ;) ), là où dans ton exemple il faudrait sous classer file et/ou recoder un tas de trucs

J'aime pas cette philosophie du « Un anneau pour les gouverner tous ».
Parce qu'après, on essaie de tout faire rentrer pour pouvoir utiliser cette méthode, quitte à dévier un peu de ce qu'on aurait du réellement faire. Par exemple ici, y'a fort à parier qu'un gus ira inventer des open/close dummy rien que pour se faire plaisir d'utiliser cette méthode…
Et à l'inverse, on va plâtrer méchamment cette méthode dans tous les coins pour traiter toutes les petites subtilités à la con (« Ah oui mais mon fichier est déjà ouvert et/ou je ne veux pas le fermer », etc), en gardant une compatibilité afin de ne pas casser les 99 autres % de l'application qui utilisent cette méthode:

def readToArray anInput
  arr = []
  begin
    if isinstanceof(anInput, file) and file.isOpen():
      open = false
    else:
      open = true
      anInput.open
    anInput.each { |elm| arr << elm }
  ensure
    if open:
      anInput.close
  end
end

(ne rigolez pas, j'ai déjà vu des trucs comme ça, y compris dans des libs python ultra-utilisées…)

Non, pour moi, un fichier ne doit pas être lu par la même méthode qu'un main ou qu'une table excel. Que le comportement derrière soit mutualisé si possible via du polymorphisme, c'est autre chose.
Ça a l'énorme avantage de pouvoir isoler les choses facilement si (comprendre « quand ») une évolution future arrivera.

On s'en fout, ton test U doit être sur que pour un type itérant, la méthode te renvoi un tableau contenant chaque élément de ce type, au dev qui développera ce type de faire les tests U qui confirme que son objet sait ouvrir/itérer/fermer

Sauf que sans aller voir ta méthode, et même avec toute la meilleure volonté du monde, sans aller voir dans ton code, je n'aurais AUCUN moyen de savoir que je dois répondre à open, each et close !
Sans parler que plus je vais aller vers les couches hautes, plus les tests que tu demandes seront impossibles à vérifier, vu la quantité effroyable de comportements qu'un simple objet devra respecter !

J'ai du mal à voir un cas où de la refacto sera plus facile à réaliser sur du dynamique que sur du statique.
Un exemple m'éclairera sûrement =)

En dynamique, on est de base pas aidé par l'IDE, même la refacto la plus simple (renommage attribut ou méthode) est un jeu de pifométrie aléatoire avec 0 certitude que le système fonctionne correctement après la refacto.
Aller, à la limite, l'introduction d'une super/sous-classe est effectivement plus simple en dynamique (rien à faire) qu'en statique (tout à faire).

Dès que tu ajoutes un attribut, une classe, que tu ajoutes un paramètre ou un polymorphisme, TOUS les endroits où était utilisé l'ancien code est à revoir.
Sauf qu'en dynamique, personne ne peut justement savoir où se trouve cette ancienne utilisation du code, vu que tout est dynamique justement.
À l'inverse, une analyse du code statique trouvera déjà la plupart de ces utilisations et les refactorera (c'est ce que fait la refacto Eclipse), et les non-vues déclencheront des erreurs à la compilation.

En java et c++ (et je pense en typage statique en général) ça revient souvent à réecrire beaucoup de choses (voir pire, jai déjà vu un rattrapage d'archi en AOP).

Et ? Où est le problème ?
Si on refactorise l'architecture, il est normal d'avoir à rattraper pas mal d'endroits dans le code.

Un code python qui va continuer à fonctionner après avoir refondu une architecture sans toucher du code à droite et à gauche, c'est plus un truc qui est tombé tout seul en marche qu'autre chose…

C'est pas parce que tu fais moins de travail que ton travail est meilleur et/ou plus robuste.
Les trucs du style « wé mais non regarde, pas besoin de toucher à ça, la magie python va faire que ça va passer quand même », c'est cool tant que la magie dure justement. Ça reste du passage aux forceps d'un truc prévu initialement pour un trou carré… qui est aujourd'hui rond, et demain triangulaire. Le jour où ça frotte juste un peu… ça se coince et généralement ça veut plus faire marche-arrière !

Tu vois, toi-même tu préfère écrire du java comme si c'était du python ;-)

Il me dit que ça prenait trop de lignes, je lui montre que non =)
Il n'a pas dit que cela devait être robuste.
Auquel cas de toute façon, Java est largement devant Python et Python moins robuste car non typé.

List<String> read(String name) throws IOException
  try (File file = new File(name)) {
    return FileUtils.readFileToString(file);
  }
}

• Pas de risque d'avoir autre chose qu'un String en paramètre
• Pas de risque de conserver le fichier ouvert en cas d'erreur lors du readFileToString (autoclose)
• Garantie que le type de retour est bien une liste de String…

def read(name):
  '''
    Lit l'intégralité d'un fichier
    @param name : chemin du fichier à lire
    @return lignes du fichier
  '''
  with open(name, 'r') as file
    return file.readline()

• Qui a fait un test U pour voir ce que ça fait si je lui passe un Int ou un Canard en paramètre ?
• Si répondu « moi » à la question précédente, ça fait quoi avec une Voiture ou un Path ou Obiwan ou … ?
• Comment ça cette fonction peut lever une exception ?
• Comment ça cette fonction peut lever une exception à 2 endroits ?
• Ça me retourne quoi ? Un tuple, une liste, un array, un dictionnaire { n° de ligne, contenu } ?

5 lignes en Java, 8 en Python, au coût de la ligne, je prend Java !!!
Et en plus, trouve-moi un seul mec qui va m'écrire ce code python du 1er coup…
Généralement, j'obtient plutôt

def read(name):
  file = open(name, 'r')
  return file.readline()

et il faut carrément une bibliothèque externe pour ça

Au prix où est Maven, je ne vais pas me géner non plus =)
Ça m'évitera même d'écrire la moindre ligne de code…
D'ailleurs, au prix où est la ligne…

FileUtils.readFileToString(new File("foo"))