wilk a écrit 1106 commentaires

Pourquoi attendre un test ? Parce que dans tous les cas il faudra bien attendre un test, le contrôle du type étant loin d'être suffisant.
Comme tu dis ça ne remplace ni la doc ni les tests donc ça fait doublon, triplon même.
Et surtout ça ne permet pas de bénéficier des avantages du typage dynamique. Je pense que l'incompréhension vient du fait de ne pas tirer parti du typage dynamique et d'y voir qu'une sorte de manque à rattraper, comme on le voit dans les exemples donnés.
Si je prend print par exemple, je n'ai pas à lui donner un string en paramètre et il n'a pas non plus à tester quel type est le paramètre, il appelle simplement __str__() de l'objet passé. Au pire, comme l'indique manawy, on utilise beaucoup plus hasattr que isinstance.

Dans le cas de types plus complexes, le premier test va lever l'erreur encore plus vite.

Le seul cas où j'avoue que ça manque c'est lors d'une refactorisation importante d'un code qui n'est pas couvert par assez de tests unitaires.

Pour le compilateur on comprend tous comment ça peut aider, pour le programmeur je ne vois pas trop.
Dans l'exemple donné foo(a: str, b: str, c: int), ok a et b ne peuvent être que des str, mais on peut toujours les inverser sans que le compilateur ou l'IDE nous aide.
Bref, ça veut remplacer la doc mais ça ne la remplace que médiocrement car c'est une syntaxe fait pour un compilateur, pas pour un humain.

Il vaut mieux avoir de côté, mais dans notre activité c'est assez facile, on a relativement peu d'investissement (à part en temps) et encore une fois, avec le filet de sécurité à la française ce que l'on met de côté ne risque pas de s'évaporer à la moindre bronchite.

En tant qu'informaticien on n'est quand même pas les plus démunis face aux paperasses. Et en France on bénéficie d'un sacré filet de sécurité qui justement permet d'entreprendre sans soucis pour soit mais surtout pour la famille ! Certes il a quelques trous mais encore une fois en tant qu'informaticien on les repère assez vite.

D'où l'intérêt de textile la syntaxe est très proche du html/css.

h1. titre 1

Les *cerises* sont %{color:red}rouges%

J'utilise stable depuis des années, sur serveur et machine de dev/maison. Quel repos de ne pas avoir à se soucier de stabiliser l'instable !
En revanche, s'appuyer sur du stable ne veut pas dire que l'on ne doit utiliser que du stable. Le tout est de définir ce qui doit être exceptionnel. Je préfère avoir quelque chose de stable par défaut et exceptionnellement changer (à l'aide de backports, virtualenv, vm…) que l'inverse avoir de l'instable pour tout et d'être obligé de stabiliser ce qui le nécessite.
En python j'utilise virtualenv, car les besoins sont différents, très peu de paquets à gérer et que je connais parfaitement, dans ce cas ça me permet d'avoir du stable, encore plus que debian (que je n'ai pas forcément à mettre à jour lors d'une maj debian), ou inversement d'utiliser des versions très récentes (mais que je maîtrise, ce qui ne serait pas possible avec tous les éléments d'une distribution).

En plus le principe du gel permet de faire le point sur la cohérence de la distribution. Il facilite également le support, l'installation de nouvelles machines, le développement etc.
Il permet inversement d'être plus à l'aise avec les versions non stables puisqu'elles le sont explicitement.

12kg de charge vélo compris ??? En autonomie complète seul j'ai minimum 15kg de bagages (tente, réchaud, nourriture, eau…), 15kg de vélo (garde boue, lumière, portes bagages etc.) J'ai jamais vu moins.

Cet été par exemple, j'ai 4 sacoches, un follow-me, ma fille et son vélo.
Autre exemple une remorque avec deux enfants ça fait 60kg facile.

C'est justement avec un chargement que RV a un intérêt, si je roule tout seul sans bagage à côté de chez moi sur un vélo léger je m'en tape un peu des montées, même à 20% (trop fort je suis).

Si le trajet n'est pas appris par coeur les carrefours sont encore plus pénalisant, il faut s'arrêter et regarder l'itinéraire.
C'est un peu comme les montées cassantes, tu vois le truc à redémarrer avec un attelage…

Oui, un fort coefficient d'énergie perdue dans le cas d'un passage à pied. C'est bien mon problème. Par exemple je tracte ma fille (avec un follow-me), du coup chaque passage à pied est très contraignant, le poids de l'attelage et le fait que ma fille ne va pas marcher vite, il faut que je la surveille etc… Peut-être un "coef pénalité" en plus du poids ?

Ne te vexes pas, il faut juste revenir au sujet "itinéraire minimisant l'énergie" et non pas de savoir qui est le meilleur grimpeur ou le meilleur vélo.
La semaine dernière j'étais sur les monts de Lacaune avec un vélo chargé, j'ai du mettre pied à terre une fois en écoutant les conseils de l'épicière qui m'a assuré que son petit neveu prenait ce raccourci, la prochaine fois j'utiliserai un velib à la place de mon surly ;-)

Du coup il faudrait tenir compte du poids du véhicule (qui peut avoir une remorque, un siège enfant etc…). Je dirai même un filtre pas de pied à terre du tout ou pas de pied à terre sur plus de x mètres.

La dangerosité pourrait déjà être traitée au niveau des courbes et carrefours. Moins il y a de carrefours moins c'est dangereux généralement. Un carrefour en tourne à gauche est plus dangereux (et plus lent) qu'en tourne à droite.

Troisième possibilité, tu n'as aucune idée de ce qu'est une côte à 20% et un vélo chargé ;-) !
Mais je suis sûr que jben pourrait calculer ça ainsi qu'intégrer la limite d'équilibre, dans l'exemple que j'ai trouvé il indique une vitesse de 1.7km/h, donc là moi, clairement je sais pas pédaler effectivement ou alors j'ai pas un vélo adapté il me faudrait un tricycle plutôt.

Attention, on va te répondre que tu ne sais pas tourner ou qu'il faut changer de guidon ;-)
Dans le même ordre d'idée les carrefours sont à éviter, même tous droits car ils obligent à redémarrer ce qui est parmi les plus consommateur d'énergie.

Merci pour ce projet !
En tant que cycliste je ne trouve pas que les montées soient un problème linéaire. Les montées ne me dérangent pas tellement c'est surtout celles réellement cassantes, au delà d'un certain pourcentage sur un minimum de distance. Je viens de faire un test l'algo ne semble pas en tenir compte, il me propose un parcours avec une montée quasiment impossible à prendre à vélo.
Comme je fais beaucoup de rando avec bagages c'est un critère essentiel, il ne faut pas avoir à descendre pour pousser le vélo.
edit : je viens de voir (excellent !) que l'interface affiche le %, celui dont je parle est quand même à 20% !

Quels sont les retours éventuels à attendre vers cpython ? Est-ce un projet qui est destiné à rester une surcouche à cpython où est-il destiné à terme à être intégré au moins en partie à cpython ?

Vu l'auteur-dev de l'article, ça n'augure que du bon !

Ca ressemble à une conf de supervisor. Quelles sont les différences entre les deux (au niveau lancement de services) ?
Est-ce qu'on trouve l'équivalent de superlance, qui permet de tester une connection à un service, sa mémoire occupée… et de le relancer au besoin ?

Que de souvenirs. Quand je pense à l'époque où j'ai pu faire tourner minix sur un atari st, de là avec quelques hacks le transformer en serveur à l'aide d'un minitel inversé ! Quelques semaines plus tard un gars se connecte et me le pirate ! première leçon ! que j'ai oublié d'ailleurs, dommage, je ne me souviens même plus de la faille en question.
Qu'est-ce que j'ai pu apprendre avec minix, c'était à la fois tellement puissant et simple à la fois, une prouesse, un régal. Et tout ce que j'ai pu apprendre j'ai pu le réutiliser tel quel sur unix sco, pas le choix, et linux bien trop longtemps après.
Minix c'était une des premières possibilité pour un non universitaire d'apprendre tout seul chez soit. Pour moi le premier open source dans toute ça splendeur pédagogique.

Merci Andrew ! et merci pour le journal, ça me donne l'idée d'aller lui écrire un petit mot tien.

On mélange tout et n'importe quoi, langage, framework, utilisateur, admin, développeur…
Si tu veux un exemple, j'ai des clients sous windows pour des applis web, je leur livre un seul exe qui se met à jour et fait des sauvegardes tout seul.
Concernant les sites internet, si c'est un nouveau site, je vais sur une page web, clic nouveau site, je rentre le nom de domaine, le nom de l'appli et de la bdd. C'est tout. Pour les mises à jour : hg push prod, c'est tout.
Un plugin pour mon appli ? config.include('monplugin')
Tout ça en python et je ne fais franchement rien d'extraordinaire, avec des outils tout kiss python, pyramid, mercurial, supervisor, nginx, postgresql…

Tant qu'à tout mélanger : un exemple plus visible où tout se fait en quelques clics ? http://odoo.com

Ceci dit on a tous remarqué que les applis en php s'installent plus ou moins facilement avec le même genre de bidouillages. Mais ça n'a pas grand chose à voir avec le langage, c'est plus une habitude qu'autre chose. C'est l'environnement qui joue beaucoup, il a pas mal évolué en python ces dernières années avec wsgi, pypi et les frameworks web, mais le langage reste le même.

Je réitère ma question, est-ce que l'environnement a évolué du côté php à ce niveau où en est t-on toujours au même point avec un vulgaire zip foutoir et une config apache centralisée ?

Tu vas trop loin, virtualenv, c'est trop compliqué pour les avantages qui sont cités. Après, ça pose d'autres problèmes mais ce n'est pas ce genre de projet où PHP est utilisé.

On parlait de mises à jour, de plugins, de configuration en ligne… Pas d'un simple echo "hello".
Dès que le projet prend un tout petit peu d'ampleur cette facilité de déploiement devient toute relative si je comprends bien.

Choisir un langage parce qu'il permet d'éviter 3 lignes dans un fichier de conf c'est un peu léger…
Pour le reste, je ne vois pas non plus le rapport entre les mises à jour, les plugins et les langages dont on parle.

Ca fait très longtemps que je ne me suis pas coltiné du PHP, quel est l'équivalent de virtualenv en python ? cad créer un environnement avec ses propres libs pip-installées par projet.

Python, la question ne se pose plus. Pyramid parce qu'un beau jour, comme tous les matins, je me réveille en me disant qu'aujourd'hui, c'est décidé, je documente et uniteste mon framework maison. Voyons voir comment font les autres… Tien, celui-là ressemble étrangement au mien et cerise sur le gateau, déjà documenté, déjà unitesté ! Je me pince. Aïe ! Voyons voir ce que ça donnerait sur une appli existante. Quelques coups de vi plus tard, ça tourne, ni vu ni connu…

Est-ce que tu as quand même regardé ce qu'il en était du glue-code ? Il me semble que pour les parties dont tu parles (authentification, mako, sqlalchemy) le glue-code ne tien que sur une poignées de lignes avec Pyramid. Où alors tu penses à autre chose ?

Et pas Pyramid, Django, Flask…
Sachant que la question qui me turlupine d'avantage, c'est pourquoi TG2 est basé sur Pylons et pas Pyramid (qui en est le successeur).