Aeris a écrit 435 commentaires

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"))

Je pense que ces objectifs n'ont rien à voir avec le fait d'utiliser un langage statique ou dynamique. Je pense même que que l'on produit assez souvent des programmes en c++ peu stables malgré son typage statique.

Oui, on peut faire du crade avec tout, certains langages étant juste plus enclins que d'autres à faire du code dégueu.

J'ai un plus gros désaccord pour le refactoring: en effet le dynamique peut poser problème lorsque l'on renomme des méthodes ou ptit trucs du genre, par contre en cas de gros refactoring (modif d'archi), il me semble que le dynamique est là bien supérieur.

Pas convaincu.
Un refacto d'archi risque typiquement de casser l'intégralité de ton code Python, cause qu'elle laisse une chiée de truc pas refactorisé car pas détecté par l'IDE car pas de typage statique donc incapable de détecter qui est impacté.
Pour l'avoir vécu sur pas mal de projets assez conséquent en python, ça se finit généralement en séance de

while not working:
    run
    debug
    correct

Au moins en Java, la refacto corrigera déjà énormément plus de choses via la puissance du refactoring des IDE cause aide du compilo et analyse statique du code, et le restant pétera directement en rouge cramoisi tant que ça sera faux.

Dans tous les cas, tu ne peux pas faire du python comme tu ferais du c++. C'est pas la faute du python ou du typage dynamique, c'est la faute au dev qui veut du typage statique dans python. Les paradigmes sont différents, faut coder différemment.

J'ai jamais dis le contraire =)
C'est même une de mes principales conclusions : le code tient en plusieurs fichiers et/ou dépasser les 200 lignes ⇒ adios le dynamique, vive le statique ! En tout cas d'un point de vue stabilité / maintenance / évolutivité.

Du coup tu lis le code des bibliothèque que tu utilise pour savoir comment t'en servir ?

En Python, clairement tu y es justement obligé.
Va faire du X509 uniquement avec la doc de la lib du même nom en Python (http://packages.python.org/pyOpenSSL/openssl-x509.html), c'est juste impossible.
Tu es obligé d'aller voir ce qu'ils attendent comme type de paramètre.
set_subject(subject): Set the subject of the certificate to subject. ne te dit pas que subject doit être de type X509Name si tu ne vas pas voir dans le code…

En Java, abstract Principal getSubjectDN(): Gets the subject (subject distinguished name) value from the certificate., plus besoin d'aller voir le code pour savoir ce qu'on manipule. Et même sans la doc, ton IDE te donnera aussi le prototype du bidule (ce qui au final est équivalent, vu la pauvreté de la doc, totalement inutile à ce niveau).

Non mais tu carricatures pour Python et me fait dire ce que je n'ai pas dit. C'est quand même un langage qui ne manque pas de ressources documentaires …

J'ai jamais dis le contraire, mais elle n'est pas complète, blindée d'erreurs, ne comporte pas de doc sur les API internes, etc.
Elle est donc globalement inutile, étant donné que je devrais quand même faire tout le taff d'aller réellement voir comment c'est fait dedans pour que ça fonctionne.
Et que je passe mon temps à lancer mon appli et à la tester à 1000% pour être sûr qu'une runtime exception ne se pointera pas le jour de la recette.

Je ne peux avoir confiance en une doc si je n'ai pas la preuve qu'elle est correcte.
Comme personne n'est capable de me donner cette preuve pour aucune des docs existantes actuelles, alors toute documentation est inutile (doc type doxygen/javadoc j'entend).

Encore une fois, non et non … ça rejoint ce que je te disais plus haut sur la gestion de ton travail d'équipe.

On peut continuer dans les postulats si tu veux :
Postulat n°4 : on a toujours une brebis galeuse dans l'équipe
Le but du jeu est de la détecter immédiatement, pas le jour de la recette.
Et le typage statique est assez efficace pour ça, ça l'obligera même à venir te poser des questions parce que le compilo gueule plutôt que de faire un truc à l'arrache qui semble plus ou moins tomber en marche subitement par moment.

Pour la doc, y'a pas à argumenter plus, c'est une vision différente que l'on a toi et moi. Ton point de confiance est dans le compilateur, moi dans les docs de qualités (et elle n'est pas aveugle ;) )

Même la doc python ou java est foireuse à souhaits, ou en tout cas ne peut pas être considérée comme fiable. Alors celles de nos projets… Je t'ai dis, j'attend toujours une doc en qui je puisse avoir confiance…

documenter son architecture et de faire une couche intermédiaire qui se chargeait de faire les opérations en proposant une interface sécurisée et sa propre doc. Et bien depuis aucun souci sur la partie interface : de la doc de qualité + des entrées sécurisées, ça permet de fonctionner de manière fiable avec une potentielle passoire derrière.

Pour les docs d'archi et de conception, je suis d'accord avec toi que c'est possible et même obligatoire. Mais pour le détail nécessaire au développeur lambda, les docs ne sont généralement pas suffisantes…
Prend l'exemple de ton API espagnole. OK, aujourd'hui ça fonctionne. Mais demain ? Si tu dois faire évoluer la partie moisie, c'est juste mort, avec ou sans doc.

C'est plus affreux à ce niveau… C'est carrément du suicide collectif !
Et niveau maintenabilité… hum… No comment =)

Si mon utilisateur final est un développeur qui fait du code merdique, ça ne me regarde pas.

Si c'est quelqu'un de ton équipe, si.
Et t'es bien content que l'intégration continue pète gentillement sur chacun de ses commits plutôt que de te rendre compte pendant une recette qui a codé grave de la daube :þ

Quelqu'un me remplace, il hérite d'une magnifique doc, de plein de schémas, qui auront pris plein de temps à faire mais assureront la pérennité des projets au delà de ma petite personne.

Des docs de conception ou d'architecture, certes, ça se fait et ça se trouve.
Mais trouve-moi une seule doc type javadoc ou doxygen où tu peux lui faire aveuglément confiance… C'est généralement blindé d'erreur de copiés/collés, de trucs refactorisés mais sans mise-à-jour de la doc, voire même pas documenté du tout.

Et en plus, avoir une doc (par exemple en python) capable d'avoir un niveau de détail suffisamment fin pour éviter les erreurs qu'auraient détectées un compilateur, c'est juste inenvisageable.
Si tu prends le add(duck) précédent, soit tu le documentes avec un simple duck : canard à ajouter, doit être de type Duck ou dérivé et autant avoir un joli compilateur pour faire ce travail de vérif en plus de perdre tout intérêt au duck-typing, soit tu le documentes avec un gros duck : canard à ajouter, doit répondre à la méthode fly, quack, swim et posséder les attributs feathers, qui, en plus de ne sûrement pas être exaustif, sera une simple plaie ambulante à maintenir…

J'aimerai vraiment pas bosser dans tes conditions…
Trouve-moi une seule doc qui soit disponible et sans erreur (avec la preuve qui va bien, hein)…
Même la doc officielle python est truffée d'erreurs en tout genre.

Postulat n°1 : ton utilisateur est une buse…
Postulat n°2 : demain, t'es plus là…
Postulat n°3 : la doc n'est jamais à jour, cohérente ni même disponible…

Étant donné qu'un utilisateur peut être utilisateur final et/ou développeur, plus le compilo te détectera des erreurs a priori, et non pas uniquement a posteriori au runtime, mieux tu te portes.
Idem, plus il est capable de t'aider (via l'IDE) mieux tu t'en porteras.

Bon, j'ai tapé trop vite au clavier, il faut bien sûr inverser correct et incorrect :þ