THE_ALF_ a écrit 531 commentaires

Du coup, si l'idée est de passer par des générateurs pour éviter de créer des listes pour les parser, il y a encore mieux:

generator_a = (s for s in some_list if s.startswith('a'))
generator_b = (s for s in some_list if s.startswith('b'))

Notez la subtile distinction.

Et pour le typage en python, il y a la solution mypy qui est assez efficace.

Effectivement, ça va un peu ralentir l'écriture du code python vu que l'on recommence à se préoccuper des types, mais d'expérience, c'est bien utile pour éviter des bugs dès qu'un projet est un peu complexe.

Je penses que l'intérêt de cette notation est de ne générer ta liste que quand tu en a besoin, mais du coup c'est con de convertir en list tes filtres. L'idée serait plutôt de pouvoir faire ici:

filter_a=filter(lambda x:x[0]=="a", some_list)
filter_b=filter(lambda x:x[0]=="b", some_list)

for stuff in filter_a:
    play_with(stuff)

for stuff in filter_b:
    play_with(stuff)

Avec cette méthode, tu ne va jamais créer de liste list_a et list_b potentiellement très longue te bouffant ta mémoire. Bien entendu, cette méthode n'est pas nécessairement adaptée à toute situation, mais il s'agit une méthode très "pythonique" de gérer le problème en optimisant la mémoire.

Je me permettrai d'ajouter la définition du Larousse: "Caviarder: Censurer en biffant". Donc on distinguerait l'action technique de dissimuler/effacer du texte (biffer), du but de cette action (censurer, donc rendre inaccessible l'information initialement présente dans le texte pour une raison X ou Y), le caviardage étant donc une méthode de censure, dont le moyen technique et le biffage. Ça me va; j'aime quand des mots différents portent des sens différents.

Et revenir à l'étymologie de caviarder sur wiktionary me semble assez savoureux (si je peux me permettre): "De caviar, car le texte censuré devient rempli de points noirs, comme les œufs d’esturgeon.". Caviarder n'est pas tant biffer un mot dans un texte, que d'en enlever ou dissimuler tout un ensemble d'information (la censure) résultant donc en un texte-caviar parsemé de tâches noires. L'étymologie de "biffer" renvoie, elle, à la seule notion de "rayer".

QED

Mon analyse:

Quand on regarde ce pdf, on se rends compte que la "faille" vient du fait que quasiment tout le texte se retrouve dans l'onglet des signets. Onglet des signets dans lequel on est censé retrouver les titres de sections/sous-sections etc.
Comment cela a-t-il été possible? Tout simplement parce que le texte n'est qu'une succession de titres de sections/sous-sections/etc, avec très peu de texte.

Donc ce qu'il semble s'être passé, c'est que les auteurs du documents ont voulu rédiger un texte très organisé en items numérotés et imbriqués. A priori pas de problème, sauf que pour faire cela, ils ont utilisés… les sections/sous sections/etc, et non pas les listes numérotées. Du coup, tout est titres, donc tout se retrouve en clair dans les signets.

Donc si il faut choisir entre "incompétence" et "malice", je crains fort que le premier est le plus probable.

Tiens, on a eu une lecture totalement opposée de la "geekitude". Personnellement, j'avais surtout vu un comportement très geek "attends, pour te connecter à mon wifi c'est simple, il faut juste que tu te connecte par bluetooth. T'as bien un IPhone?" vs le comportement normal et non-geek du papier coincé sous la télé avec le code wifi…

Et donc sérieusement, il y en a qui se sont dit qu'il est difficile de donner accès à son wifi, et ont imaginé un procédé basé sur la simplicité du bluetooth?

De plus, ce que je retiens du résumé de la thèse, c'est surtout que le reverse-engeneering a permis de détecter quelques failles menant à une attaque "denial of service" et une attaque "man in the middle"…

Franchement, un bout de papier sur lequel est écrit le mot de passe WIFI et qu'on passe aux invités, c'est compliqué? Ça me semble en tout cas bien plus sécurisé.

Donc on se plaint de la place prise par les mail sur les serveurs, et on donne une description… en vidéo plutôt qu'en texte. Logique?

Placer le java entre guillemet comme ça: -"java" semble marcher. Je ne sais pas pourquoi.

Il faut se méfier de "même colonne => on peut envisager une chimie dessus", le raccourci est bien trop rapide. Une chimie où le silicum remplace le carbone marche très différemment (liaisons entres atomes de silicium très instables, alors que la riche chimie du carbone se base sur des liaisons entre carbone très stable…). Pour remplacer le phosphore par l'arsenic, un fameux papier prétendant avoir obtenu des bactéries vivant à base d'Arsenic à rapidement été retiré…

Par contre le fait que la phosphine puisse être un marqueur de vie n'a a priori rien d'absurde, étant donné qu'il s'agit d'une molécule simple à base de phosphore, qui est un élément clé du vivant. Une meilleure analogie avec la phosphine est le cyanure. Le cyanure est très toxique pour de nombreuses formes de vie, mais est considéré comme une source possible de molécule "biologiques" (on se place cependant ici plutôt dans un cadre de marqueur pour l'émergence de la vie, plutôt que de marqueur de vie déjà en place).

Ma principale crainte derrière cette annonce est que l'on risque fort de ce retrouver avec ce qu'il s'est passé avec le méthane martien: des quantités pas forcément facile à expliquer et dont une explication (parmi d'autres) pourrait être expliquée par la présence de la vie. Et même si il y a de la vie sur Venus, rien ne prouve n'ont plus que l'on se trouve avec des formes de vie extra-terrestres on sens propre (il pourrait s'agir de contamination terrestre, que ce soit ancienne via des météorites… ou par les sondes envoyées depuis plusieurs décennies).

Bon, j'éteins mon mode "rabat-joie" (mais je serait heureux d'avoir tort ;-) )

Tant que l'humain est plus intelligent que la machine, il me semble raisonnable d'attendre à ce que ce soit à l'humain d'apprendre à utiliser une machine, et non l'inverse. Sinon, on en est réduit au plus petit dénominateur commun.

Ce mode de pensée qui voudrait qu'il ne faut surtout pas que l'on attende d'une personne qu'elle ne réfléchisse pour utiliser un ordinateur (ou tout autre objet courant, d'ailleurs) me semble pour le moins perturbante et réductrice… mais malheureusement très présente dans notre mode actuel.

Sérieusement, je pensais que le système de fichier "case insensitive" était un bug de Windows de l'époque W95/W98 qui avait été corrigé lorsqu'ils étaient sortis du FAT pour le NTFS. C'est encore d'actualité pour les Windows actuels (je n'ai pas testé depuis W98)?

J'ai du mal à comprendre l'intérêt d'implémenter le foutoir qu'il y avait à avoir plusieurs manières différentes de nommer un même fichier.

Il s'agit au contraire de favoriser l'internet fixe par rapport au mobile, car moins énergivore. Ils parlent d'interdire les forfaits illimtés en données pour les réseau mobiles, et rendre le tarif des forfaits mobiles proportionnels au volume de données, tout en précisant que cela ne concerne pas les forfaits fixes. En même temps, ils préconisent le développement du très haut débit, pour inciter à la connexion en Wifi.

J'ai beaucoup essayé de thèmes divers et variés, et je finis toujours par retourner sur Solarized light (décliné du coup dans mes thèmes qt/gtk). Parmi les différentes suggestions, je notes quand même gruvbox (qui ressemble pas mal à solarized), à tester.

J'étais pendant longtemps resté sur des thèmes sombres (et en particulier zenburn) avant que ça ne revienne à la mode. Mais maintenant, l'age aidant, ils me fatiguent très rapidement les yeux… Les thème clairs restent les seuls que je puisse utiliser confortablement.

Pour le "copyleft sauf exception" je pense que tu parles du "problème" de la licence double proprio/libre. Oui, ça peut être hypocrite avec une licence libre "publicitaire" cachant du proprio, mais ce n'est pas proprement lié au copyleft/permissif.

Je ne vois pas ce dont tu parles avec le copyleft qui se fout du code, et en quoi cela permettrait plus de fermer le code (le premier qui distribue aura toujours le droit de finalement fermer son code, quelle que soit la licence… reste au reste du monde de forker la dernière version libre du code).

Et personnellement (c'est tout autant subjectif, et n'est pas directement lié au "qui est le plus libre", mon point étant que cette distinction n'as pas de sens en soi) je trouve le copyleft intéressant car il donne (paradoxalement?) un coût au logiciel libre. Non pas un coût financier (tu veux utiliser le code, tu donne de l'argent en échange), mais un coût intellectuel (tu veux utiliser le code, tu donne tes modifs—avec la même licence—en échange).

Pour la théorie et la pratique, sincèrement; il y a de très bons projets qui vivent en copyleft, et de très bons projets qui vivent en "permissif", donc je ne vois pas le problème.

Tout dépends ce que l'on entends par "utilisateur". Si par utilisateur tu entends ceux qui vont utiliser l'application, alors oui, ils ont exactement les même droits, et pour ceux-ci, "copyleft" ou "permissifs" sont tout aussi libres (libre utilisation, installation et copie du logiciel, …).

Cela change pour les utilisateurs du code (et non de l'application) pour ceux-ci, une licence "permissive" est plus libre, car ils ont plus de possibilité d'utilisation du code qu'avec du "copyleft" (par exemple la possibilité de changement de licence, voire de "propriétisation" du code, …).

Mais cela change aussi du point de vue du code lui même. Pour celui-ci, la licence "copyleft" est plus libre qu'une licence "permissive", notamment grâce à la garantie qu'il ne peut pas voir (ou plus difficilement, je simplifie) sa licence changer, et qu'il a donc la garantie de rester libre.

Il faut faire attention avec ces discours (sans fin) entre "plus libre" ou "moins libre" qui n'ont pas de sens dans l'absolu, mais dépendent du contexte. Plus de liberté pour l'un peut (et, en général, va) signifier moins de liberté pour l'autre.

PEP3101: "The best way to use string formatting in a way that does not create potential security holes is to never use format strings that come from an untrusted source."

Le plus dur est de tromper la ligne "[Age: …" sans faire planter la ligne "Printing…". J'ai pu trouver une solution qui marche en enlevant la ligne "Printing…", mais sinon je bloque :D

Représenter une idéologie n'est ni la défendre, ni la contester, c'est la représenter. Il s'agit d'une action neutre. Il me semble normal que l'on puisse retrouver tout symbole (même une croix gammée) si on veut pouvoir en parler. Et quand bien même on voudrait donner un sens militant à ce type de site (ce qu'il n'est pas), ce n'est pas en gommant les croix gammées que l'on combat l'idéologie nazie, et ce n'est pas en donnant accès aux croix gammées que l'on promeut l'idéologie nazie.

Cela me gênerait beaucoup de ne pas trouver toute une collection de symbole sur ce type de site, pour la seule raison qu'ils pourraient représenter des idéologies que l'on rejette.

Ceci dit, il y a aussi à mon avis un bug du coté de libreoffice, qui peut se fier au suffixe plutôt qu'au véritable format du fichier. Je dit "parfois" parce que ça dépends du cas:

Test 1:

Je crée un fichier toto.odt, puis je fais une copie nommée toto.docx. Libreoffice ouvre sans problème toto.docx. Si je le modifie et l'enregistre, pas de problème. un file toto.docx me dit bien toto.docx: OpenDocument Text. Bref ici, libroffice se fie au format du fichier et non au suffixe.

Test 2:

Je crée un fichier tutu.docx, puis je fais une copie nommée tutu.odt. Je retrouve le problème rencontré ici: libreoffice veut voir un .odt, même si file tutu.odt reconnaît bien un tutu.odt: Microsoft Word 2007+. Ici, libreoffice se fie au suffixe, et non au format du fichier.

Il y a en tout cas un problème de traitement du fichier en fonction du format détecté/suffixe… On dirait que si le suffixe dit que c'est un format natif, libreoffice lui fait confiance, sinon il détecte automatiquement ce que c'est.

En gros, (si j'ai bien suivi) il s'agit de restreindre l'accès à une fonctionnalité permettant de bloquer le téléchargement de certaines parties de la page (en ciblant les pubs, donc). Est-ce que ce n'est pas facilement contournable en déplaçant l'endroit où le filtre est effectué? C'est à direr tout télécharger, mais n'afficher que les éléments non identifiés comme publicité (ou remplacer les éléments reconnus comme inadéquats par des éléments neutres ou invisibles).

Au passage, on perdrait certes l'avantage (appréciable) de restreindre la quantité de données à télécharger aux seules donnée pertinentes, mais cela rendrait probablement le bloqueur plus difficilement détectable par le serveur web…

Page 3 du manuel de lastpage…

Il faut remplacer le \pageref{...} par un \pageref*{...}

Oh, c'était pour avoir une numérotation des section qui recommencent à 1 pour chaque partie. Pour ne pas paumer hyperref dans la procédure, il faut simplement mettre ces 3 lignes après avoir invoqué hyperref (et donc déplacer l'invocation de hyperref dans le ddpolycommon).

Les réglages par défaut de hyperref donnent un rendu assez laid des liens (encadrés en rouge). Une petite conf simple que je met systématiquement en place dans le préambule:

\usepackage{color}
\definecolor{citecol}{rgb}{0.3,0.05,0.1}
\definecolor{linkcol}{rgb}{0.1,0.3,0.05}

\usepackage[breaklinks=true,pdfborder={0 0 0},colorlinks=true, linkcolor=linkcol,citecolor=citecol]{hyperref}

\pdfsuppresswarningpagegroup=1

Cela permet de mettre les liens du doc en couleur, ce qui est plus lisible à mon avis.

En bonus, le \pdfsuppresswarningpagegroup=1 permet de supprimer pas mal de warnings du fait de la structure des pdf générés par inkscape.

Il y a une portion de code bizarre dans ddpolycommon.tex:

\makeatletter
\@addtoreset{section}{part}
\makeatother

L'enlever résout le problème. Je ne sais pas quel avait été le but de la manœuvre avec cette commande, mais elle pose plus de problème que ce qu'elle voulait résoudre, à mon avis…