GuieA_7 a écrit 675 commentaires

À noter que str.join() prend juste un itérable, et donc "\n".join([repr(m) for m in monkeys.values()]) peut s'écrire plus simplement "\n".join(repr(m) for m in monkeys.values()).
Même remarque avec deque().

J'imagine que pour trier, il faut charger toutes les données, donc pas d'intérêt de retourner un itérateur.

Oui certainement, ça serait hypocrite de faire croire que la fonction arrive à travailler 'en flux' (sans tout charger) alors que ce n'est pas possible. Et derrière si tu veux un itérateur sur la liste retournée c'est très peu coûteux de te le faire (alors que le contraire est moins vrai).

sorted renvoie déjà une liste: https://docs.python.org/3.8/library/functions.html#sorted

Et pourtant, sacrées chevilles :)

À l'époque, j'ai eu quelques temps une extension rigolote qui (en référence aux nombreux changements de nom) générait un nom aléatoire au démarrage, genre "Ice Armadillo".

• Mettre ton titre tout en majuscule dans l'espoir d'augmenter la visibilité de ton message a sûrement été juste vu plus comme un manque de respect qu'autre chose (la Nétiquette toussa).
• Si tu es directeur logistique, tu as mieux à faire que de coder un logiciel. C'est un métier, et visiblement pas le tien ; payes des professionnels pour le faire. Primo coder un logiciel ça ne consiste pas juste à l'écrire à l'instant T, il faut ensuite un suivi (corriger les bugs—il y en a toujours --, gérer les demandes d'évolutions, gérer les mises à jours des bibliothèques sous-jacentes…) et tu ne seras pas le premier à te rendre compte que tu n'as pas le temps. Deuxio écrire un bon logiciel ça demande plus de compétence que juste connaître un langage (de la même manière qu'écrire un bon roman ce n'est pas juste connaître la grammaire) ; c'est pour ça que ça prend des années (que ce soit à l'école ou à côté).

Je pense qu'avec une classe Case et une liste de liste d'instances de cette classe on aurait un code un peu plus joli. Autant l'unpacking (ex: a, b, c = foobar ) est une fonctionnalité cool de Python, autant là ça ne me semble pas très pertinent ; en effet vous passez votre temps à unpacker des tuples (il faut bien se rappeler de la sémantique de chaque élément du tuple), à avoir des variables inutiles (tous les éléments du tuple ne sont pas utiles à chaque fois), et à reconstruire des tuples (vu qu'ils sont immuables).

Avec des instances, ce code :

def tout_connaitre() :
    for ligne in range( hauteur ) :
        for colonne in range( largeur ) :
            (bombe, connu, nbalentours, drapeau) = cases[(ligne, colonne)]
            connu = True
            drapeau = 0
            cases[(ligne, colonne)] = (bombe, connu, nbalentours, drapeau)

deviendrait par exemple :

def tout_connaitre():
    for ligne_cases in cases:
        for case in ligne_cases:
            case.connu = True
            case.drapeau = 0

Hop une f-string pour la route:
print( "Sur les",nbombes, "bombes, il vous en reste",nbombes-nbdrapeaux, "à trouver.")
peut s'écrire plus simplement:
print(f"Sur les {nbombes} bombes, il vous en reste {nbombes - nbdrapeaux} à trouver.")

Bonne nuit !

Oui tout à fait, erreur d’inattention toussa.

Bonjour,

je ne vais pas faire une PR GitHub (je ne saurai pas tester que je n'ai rien cassé). Mais comme j'aime bien relire du Python, je me permets quelques petites remarques, parce que le code est plutôt de bonne facture.

• À beaucoup d'endroits (pas partout) on trouve des logging.debug("Log in %s" % logfile) ; il est préférable d'écrire logging.debug("Log in %s", logfile) car l'interpolation de chaîne ne sera faite que si le message est affiché (le niveau est DEBUG ou moins dans cet exemple).
• logging.debug("ici: %i %s", i, cmd[i]) j'imagine que le "ici" est un reliquat.
• if type(tunnel) == AutoTunnel: je pense qu'un if isinstance(tunnel, AutoTunnel): est plus propre (même si au final tester les types c'est pas très élégant, et genre une méthode/propriété "is_auto", par exemple, serait plus appropriée je trouve).
• if t.status != 'ESTABLISHED' and t.status != 'LISTEN': => if t.status in ('ESTABLISHED', 'LISTEN'):
• Il y a beaucoup d'utilisation de eval() qui gagneraient à être remplacées par des getattr() ; outre le caractère sécurité, on évite aussi de reparser du code à chaque fois (eval() est vraiment à éviter ; je doute m'en être servi en presque 20 ans de Python).
• Dans la mesure où Python 3.8 est requis, tu peux utiliser à moult endroits les f-strings qui sont vraiment super sympathiques.

---

Il y a beaucoup de double-recherches dans les dictionnaires, quand une recherche simple sera plus efficace et souvent plus compacte.

if forward in self.forwards:
    self.forward = self.forwards[forward]
else:
    self.forward = "unknown"

peut s'écrire simplement self.forward = self.forwards.get(forward, "unknown").

De la même manière le bout de code suivant est intéressant (car plusieurs améliorations sont possibles)

    def __repr__(self):
        reps = [self.header]
        for t in self.tunnels:
            reps.append(str(self.tunnels[t]))
        return "\n".join(reps)

On utilise .values() vu qu'on n'a pas besoin de la clé:

    def __repr__(self):
        reps = [self.header]
        for tunnel in self.tunnels.values():
            reps.append(str(tunnel))
        return "\n".join(reps)

On utilise .extend() et une generator expression pour éviter d'avoir N appels à append() tout en étant plus court:

    def __repr__(self):
        reps = [self.header]
        # Remarque 1: pas besoin de mettre une autre paire de parenthèses car le generator est le seul paramètre
        reps.extend(str(tunnel) for tunnel in self.tunnels.values())
        # Remarque 2: version alternative avec map()
        # reps.extend(map(str, self.tunnels.values()))

        return "\n".join(reps)

Avec les nouvelles fonctionnalités d'unpacking de Python 3, on arrive à ce résultat qui a un petit goût de programmation fonctionnelle plutôt cool:

    def __repr__(self):
        return "\n".join([self.header, *map(str, self.tunnels.values())])

---

if c.raddr:
    raddr, rport = c.raddr
else:
    raddr, rport = (None, None)

==> raddr, rport = c.raddr or (None, None)

---

En espérant avoir été utile.
Bon week-end !

L'illustration (très jolie par ailleurs), aussi utilisée en page d'accueil sur https://yunohost.org, parle de Owncloud, mais visiblement le projet est passé à son fork NextCloud. Une petite mise-à-jour serait de mise j'imagine.

Merci pour la dépêche, le projet semble soigné.

C'est vraiment important de garder l'exclusivité sur ce genre de petite merveille, il doit sûrement y avoir plein de gens prêts à acheter des goodies Clippy.

Rust a été nommé comme ça parce que justement il n'inventait rien, il se base sur ce qui a été fait par les autres langages, et essaie d'en corriger les erreurs.

Même si c'est l'explication qu'on trouve sur wikipedia par exemple, ce n'est pas la vraie origine (ceci dit ça a j'imagine aussi été gardé pour le double sens) :

https://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

TL;DR: Rust is named after a fungus that is robust, distributed, and parallel. And, Graydon is a biology nerd.

(Graydon étant un des créateurs)

À ma connaissance Parrot est mort (je n'ai jamais trouvé de gros intérêt au projet, mais j'étais quand même curieux de voir ce qu'ils arriveraient à faire).

Par ailleurs, je ne compte plus le nombre de liens et de journaux ici qui déplorent le système de dépendances de Python, et les soucis pointés ne sont pas présents chez l'autre.

Les gens du CPAN ont vraiment une solution à ce problème, ou bien le problème existe quand même mais on en n'entend juste pas (ou moins) parler ?

Non django n'impose heureusement pas l'utilisation d'un framework JS ; mais libre à toi de choisir celui que tu veux (React, Vue.js …) si tu veux faire une One Page Application (c'est ce que je comprends de "qui n'ouvre pas pleins de pages html" mais ce n'est pas super clair). Bien que beaucoup de projets ne semblent pas très actifs, il y a pas mal de réponses sur PyPI pour la recherche "django react": https://pypi.org/search/?q=django+react

Ce que tu cherches à faire n'est pas très clair de manière générale ; si tu veux un Wix-like libre clé en main, cherche un Wix-like libre ; il en existe peut-être, peut-être même qui utilisent entre autres django (j'ai des doutes mais bon). Et s'il n'en existe pas, libre à toi d'en coder un (avec django ou autre). Mais se lancer dans django (qui est juste un framework, il faut coder derrière) et s'attendre à avoir un équivalent à facebook/twitter/instagram/wix clé en main juste en installant une app django, c'est probablement faire fausse route.

En espérant avoir éclairé quelques points.

l existait avant un moteur (en Java) (dont j'ai oublié le nom) qui était décentralisé peer-to-peer. On l'installait sur son PC et il indexait en permanence le Web. Il était pas efficace mais j'espérait qu'il progresse…

J'imagine que tu parles de https://yacy.net/
Je ne m'y suis jamais mis (et je m'aperçois que ne je fais pas tant de recherches génériques que ça, souvent j'esquive Qwant pour rechercher directement sur Wikipedia/Wiktionray…), et donc je ne sais pas à quel point ça fonctionne, mais le repo a l'air de bouger encore.

Comme d'habitude la version 2.2 sera encore maintenue jusqu'à la sortie, l'année prochaine, de la version 2.4. Cela vous laisse donc 1 an pour faire tranquillement votre migration. Vous pouvez donc attendre quelques versions de correctifs si ça peut vous rassurer.

On sort généralement une version corrective par mois ; j'ai préféré avancer la sortie de 2.3.1 car il y avait des petits soucis avec l'installation du paquet (donc pas de régression au cours du fonctionnement de l'application, mais des problèmes --contournables à la main—que je trouvais dommage, surtout pour des gens qui feront une première installation).

Je suis globalement confiant sur les régressions ; vous travaillons pour nos nouveaux clients avec la version 2.3 depuis qu'elle est en RC1 (ce qui nous a permis de corriger quelques bugs mineurs).

Et en général les bugs sont corrigés très rapidement après qu'ils sont rapportés ; si basculer sur une branche GIT ne vous fait pas peur, vous pouvez avoir votre version corrigée en 1 poignée de jours (par exemple la branche v2.3.2 sera disponible bien avant d'être fusionnée dans v2.3 lors la release officielle de la version 2.3.2).

Évidemment le mieux est de tester votre workflow sur la 2.3 avant de l'utiliser en production, afin de nous remonter les éventuels problèmes (il n'y a pas de secret, parfois mêmes des bugs triviaux passent au travers des mailles du filet pendant des mois parce que personne ne se sert d'une fonctionnalité d'une certaine façon, ou ne prend le temps de faire un rapport de bug plutôt que de contourner le souci).

J'espère que tout ira bien avec votre migration !

De souvenir, il y a quelques années une personne avait demandé de l'aide dans le forum pour trouver une licence qui oblige à envoyer les patches à l'upstream ; nous en avons trouvé une nommée RPL il me semble, qui était listée comme OpenSource par le site de l'OSI, mais pas considérée comme libre par la FSF/Debian…

On parle évidemment de licences assez obscures, les licences majeures qui représente 99.9% des cas d'utilisations n'ont pas ce souci.

… pour la série de journaux centrés sur Ada; (même si c'est suite à un de mes commentaires, c'est toi qui fait le boulot.

Je suis surpris de voir dans la liste que l'atelier Jeux Vidéos de l'EPN des Rancy travaille avec Unity, un moteur de jeu propriétaire, surtout quand il existe maintenant au moins Godot en alternative libre sympathique (il y a quelques années ça aurait plus compliqué de proposer une alternative libre accessible aux non développeurs).

Ils font évidemment ce qu'ils veulent, et la promotion des logiciels n'est qu'un de leurs combats (ils ne sont pas obligés de tous les mettre en pratique à chaque atelier), mais la présence de cet atelier dans un Agenda du libre est un peu hors sujet.

C'est toujours super intéressant je trouve ces compilateurs écrits dans le langage compilé (le côté Dogfooding notamment).

Le site du projet (à moins que j'ai raté quelque chose) est plutôt chiche en informations ; on imagine qu'un tel projet a du prendre à son créateur bon nombre de mois de travail, dommage d'aussi mal le présenter. Par exemple, si le compilateur est en lui-même très portable, j'aurai bien aimé connaître les architectures cibles (pour les binaires générés par le compilateur donc).

Merci pour la découverte !

Pas forcément. Par exemple (chiffres pipo), beaucoup de gens préféreront pondre une application avec un langage A en une semaine, et la corriger ensuite pendant 2 semaines de plus (après moult rapports de bug), plutôt que de faire une application similaire très peu buggée avec un langage B, mais en 2 mois.

Au final tout le monde veut trouver la métrique qui démontrera incontestablement au monde entier que son langage fétiche est le meilleur…

PS: pour Ada, langage que j'estime beaucoup (du peu que je connais), j'aimerai bien voir des dépêches LinuxFR nous présentant des applications libres écrites avec (parce qu'à titre personnel ça me fait une belle jambe que ça soit très utilisée par une partie de l'industrie qui ne fait quasi que du propriétaire), mais j'ai peur que ça n'existe pas vraiment.

s/Antialising/Antialiasing

Genre bytes = b"rgb FF0000FF"

(à terme je te conseille aussi d'utiliser with pour ne pas avoir à fermer ton pipe explicitement).

Il semble que vous ayez réglé votre navigateur pour avoir le header "Referrer-Policy: no-referrer", ce qui n'est pas supporté par la protection contre les CSRF.