Plusieurs développeurs qui apprennent python alors qu'ils savent déjà programmer dans des langages de plus bas niveau (notamment C et C++) ont du mal à complètement saisir le fonctionnement des variables, du passages des variables aux fonctions, du scope des variables et de la notion de mutabilité.

Ici est un exemple d'une très longue discussion sur le sujet: https://discord.com/channels/323076998576603137/358724995159031820/955386313698320395

Ici est un autre exemple de développeur C qui éprouve des difficultés en python: https://discord.com/channels/323076998576603137/358724995159031820/955447473340555324

Je propose d'écrire un article en long en large qui viendrait apporter tous les éclaircissements sur le sujet. Dans cet article, je pense qu'il sera judicieux d'expliquer:

• La nature complètement orienté-objet de python (aucune primitive, tout boxé dans des objets)
• La différence entre un objet immuable (bool, int, float, str, bytes, tuple, frozenset) et muable (bytearray, list, dict, set, object)
• La notion de scope, comment python remonte les fonctions dans l'ast pour lire des variables, où python sauvegarde les variables (par défaut, nonlocal, global)

Quelques liens, de quoi s'inspirer

• https://zestedesavoir.com/tutoriels/3163/variables-scopes-et-closures-en-python/
• https://discord.com/channels/323076998576603137/358724995159031820/955394903855202324
• https://discord.com/channels/323076998576603137/358724995159031820/694232315135524945

D'ailleurs je me dis que ce tutoriel pourrait avoir sa place sur Zeste de Savoir... 🤔

Sujet de l'article

Hello la team NaN

ça vous intéresserait, que j'écrive un truc de base pour les bots discords en python ?
(un dossier python dans le dossier "bots-discord")
avec dedans, un premier truc simple (en 1 seul fichier)
et après, un truc un peu plus avancé, avec des "cogs" (des fichiers que tu importes pour regrouper tes commandes en gros) ?
rien de très fancy, mais un début quoi.

?

L'ancien index.py a été retiré dans une précédente PR mais nous avons oublié de modifier le README/how-to-contribute en conséquence

Sujet de l'article

Bonjour,

Je souhaite écrire un article sur le type array de php et le fait qu'il s'agit plutôt d'une forme de dictionnaire. L'idée vient notamment du fait d'un utilisateur qui dans le salon javascript pensais par confusion que les objets de js étaient des arrays.

Mon plan actuel de l'article serait sous cette forme:

• présentation de l'array php.
• présentation des trois types "majeurs" de collection (tableau, tableau associatif et set) dans une approche plus d’algorithmie (language agnostic).
• mise en correspondance de l'array php et des définitions précédentes.
• conclusion par une revue de différentes fonctions qui manipulent des array et qui les traitent ou non comme de réels arrays.

Il s'agira donc plutôt d'un article destiné aux débutants avec la question des arrays php comme partiellement prétexte pour revoir les collections :)

Lorsqu'on est sur un des articles sur la page d'accueil, il n'existe aucun moyen de revenir au niveau de l'arborescence principale du site.

C'est un peu gênant pour la navigation.

Il est possible de demander à google de gratuitement indexer une page grâce à ça

https://support.google.com/webmasters/answer/9012289?hl=fr#request_indexing

URL de l'article concerné

https://hub.notaname.fr/langages/python/programmer-en-python-quel-ide-choisir

À propos de cet article

Y a un petit soucis c’est que atom n’est plus du tout supporté. Faudrait peut-être ajouter « abandonné » ou « plus maintenu » dans le con. Sinon le retirer de la liste serait dommage.

Coucou
On pourrait faire les suggestions de ressources via des issues, plutôt que de passer directement par des PR ?
Exemple :

Type : Tuto
Format : Vidéo
Tags : game-dev, UE4, animation
Langue : FR
Lien : https://www.youtube.com/watch?v=MgujyPVJfL0

Ce qui permet ensuite de discuter de la suggestion avant de l'ajouter, et c'est plus simple et rapide à faire pour ceux qui veulent juste faire une suggestion sans se demander ou mettre les infos, comment respecter le bon format etc ..

Pour le moment le site manque cruellement de métadata qui pourrait être utilisé pour que l'embed automatique après le partage du lien soit jolie.

Sujet de l'article

J'ai écouté ce podcast hier changelog #480 - Git your reset one où l'intervenante parlait de cet article Git Organized - A Better Git Flow qu'elle a écrit à propos d'une méthodologie pour nettoyer ses branches sur git avant de les push sur github pour les proposer dans une pull-request.

Alors le prof de git qui sommeille en moi (il sommeille pas tant que ça) a quand même beaucoup de choses à redire de cet article. Déjà la manière dont elle utilise reset est dangereuse, elle reset systématiquement sur origin/main sans prendre en considération que la branche origin/main et sa propre branche peuvent avoir divergées, le résultat est qu'elle retrouve dans son working directory non seulement la différence avec tous les commits de sa branche (résultat voulu) mais également toute la différence des nouveaux commits introduits entre temps sur la branche main (oops). Ensuite il y a l'utilisation de --force au lieu de --force-with-lease, ON NE FORCE-PUSH JAMAIS bordel.

Le deuxième truc qui m'a choqué c'est qu'apparemment ce serait super novateur de faire comme elle fait, au vu d'avoir été bien référencé sur hackernews et de se faire inviter dans des podcasts. Il y a donc full gens qui faisaient n'importe comment avant et qui maintenant font comme elle préconise de faire et ça m'énerve.

Je suis donc assez trigger que pour vouloir écrire mon propre article sur comment on nettoie une branche, sans mentionner le sien et qui expliquerait la manière propre de faire. Parce qu'au final, utiliser reset pour nettoyer ses branches n'est pas si con que ça (surtout lorsque le travail s'étale sur plusieurs jours et qu'on veut balancer des commits "wip" sur github, juste histoire d'avoir un backup) mais qu'il y a aussi moyen de faire encore mieux avec des rebase -i, des commit -p et des commit --fixup.

Sujet de l'article

Bonjour tout le monde, j'espère que vous allez bien ! 😄

Après avoir discuté avec Martin de baptiste dans le salon #bot-discord, je suis venu à la conclusion que les ressources présentes dans le salon étaient relativement maigres et / ou ne permettaient pas de prendre une direction claire pour les nouveaux développeurs.
Pour cause, les messages épinglés traites essentiellement de détails dans certains wrapper, la commande !devbots est axée sur la théorie et la communication async avec l'API Discord (rien de spécifique au bot-dev et à ses défis), etc.
En somme, aucune direction n'est prise tant le sujet de la communication avec l'API Discord est vaste et ne se limite pas au bot-dev.

Pour ces raisons, je trouve qu'il manque un outil qui permette aux personnes qui ont une idée, mais aucune connaissance de l'API et des technologies auxiliaires, de pouvoir se lancer en sachant quoi et où regarder (je rappelle que selon le règlement, tout ce qui est lié au bot-dev doit être fait dans le salon #bot-discord hors dérogation).

L'idée est la suivante; mettre à disposition un article permettant d'avoir accès, de manière centralisé; aux prérequis, aux technologies nécessaires en fonction des idées de la personne, aux documentations et aux guides liées à ces différentes technologies.
Ainsi, l'accès à ces dernières est plus linéaire, la personne n'a plus besoin de demander de l'aide systématiquement pour des features qui font intervenir d'autres chose que simplement l'API et / ou le wrapper, et l'expérience développeur est en général plus agréable.

Thread original : https://discord.com/channels/323076998576603137/1008712423257153598/1008715451028734092

Sujet de l'article

Suite aux conversations qu'on a eu ici et ici, il s'avère qu'il y a une grosse incompréhension sur la notion de "package" en python, encore plus sur les différences entre imports relatifs au working directory, imports relatifs au package et imports absolus.

Sur base des exemples que j'ai donné dans discord, il s'agirait d'écrire un article qui explique les différentes variables __file__, __name__ et surtout __package__. Il s'agirait également de montrer que la manière d'exécuter un script python (avec ou sans -m) impacte la notion de package. Pour finir il s'agirait de donner des guidelines sur comment structurer un projet python mais sans entrer des les détails de packaging type setup.py.

En ce qui concerne les ressources existantes, la documentation officielle de python (The import system) est le document qui est à ma connaissance le plus complet. Il s'agit d'un document de référence (au sens Diátaxis du terme), ce type de document s'adresse à un publique plus avertis et n'est pas adapté aux débutants. Entre autre, la lecture de ce document n'aide en rien quant à la résolution de problème type "ImportError: attempted relative import with no known parent package"

L'indexeur est naze, on se retrouve souvent avec des diffs qui n'ont rien à voir avec les articles en cours de modification et on passe notre temps à essayer de réparer les problèmes.

On a eu diverse discussions sur discord, on a déjà proposé d'arrêter de sortir l'information depuis l'historique git, de sauvegarder (dupliquer donc) l'information à part dans un fichier tout propre qu'on pourrait gérer nous-même.

Ensuite @Equinox4 a remarqué qu'il y avait déjà une fonctionnalité d'indexeur dans jekyll et qu'il suffirait peut-être de juste l'utiliser plutôt que de faire de la merde avec nos outils fait maison

Enfin bref, voila une issue pour centraliser nos discussion

Sujet de l'article

Hello,

J'aimerais proposer d'écrire un petit article pour debunk à l'aide des mathématiques combinatoire le mythe comme quoi imposer des classes de caractères dans un mot de passe renforcerait sa sécurité.

Le postulat serait simple, dans un mot de passe de minimum 8 caractères, si on demande d'avoir au minimum une majuscule, alors on sait que pour au moins un des caractères du mdp il n'y aura que 26 choix possible: une lettre majuscule. On répèterait la même chose pour une lettre minuscule, un chiffre et un caractère spécial et on ferait le calcul du nombre de combinaisons possible.

Ensuite on répèterait la même chose mais en imposant que des lettres minuscule, on calculerait les combinaisons possibles et on verrait à partir de quel longueur on atteint la sécurité du 1e mot de passe. (spoiler: 10 lettres).

On ferait ensuite le calcul mais en n'imposant plus aucune règle, càd qu'on laisserait l'utilisateur utiliser les caractères qu'il veut (limité au même alphabet) et on regarderait quand est-ce qu'on atteint le même niveau de sécurité (spoiler: 7 caractères).

Il y aurait ensuite une section pour présenter d'autres désavantages des classes de caractère. comme par exemple ceux qui utilisent des password-manager et qui vont générer des mots de passe de 20 caractères complètement aléatoires. Il n'y a pas de garanti qu'il y aura chacune des classe de caractère présente et pourtant il s'agit ici d'un mot de passe beaucoup plus sécurisé.

La conclusion serait d'inviter le monde à changer sa politique par défaut d'un minimum de 8 caractères avec des classes imposés à un minimum de 10 caractères sans classes imposés. La sécurité pour ceux qui n'utilisent que des lettres minuscule serait assuré par les 2 caractères en plus et la sécurité pour tous les autres utilisateurs plus sérieux serait augmenté.

En terme de post-conclusion, un rappel qu'un mot de passe seul n'est pas suffisant, qu'il faut aussi TLS, un hash lent et un salt avec une explication ne sont pas abordés dans le présent article et en donnant des liens vers des ressources externes. On pourrait aussi penser rédiger qqch en français à ces sujets là et également le publier sur le blog.

Le readme actuel ne traite que comment contribuer, il ne présente pas encore le site. Ces infos sont également manquantes de l'index à la racine du site.

Sujet de l'article

Motivation

Malgré une relativement bonne base de développeurs seniors et de professeurs, Scala a toujours peiné à attirer de nouveaux développeurs en particulier de jeunes développeurs. La communauté du langage semble s'accorder sur trois principales causes:

• La syntaxe parfois ésotérique (notamment avec le mot clé implicit en Scala 2 qui signifiait 3 choses différentes).
• La communication assez pauvre en dehors de ceux qui connaissent déjà le langage.
• Le manque de cours s'adressant aux vrais débutants. La plupart des cours "pour débutants" rentrent dans des détails peu pertinents pour les débutants et partent du fait que les lecteurs ont déjà certaines connaissances en programmation.

Le but de ces "cours" est de permettre aux débutants de découvrir Scala et d'en apprendre les bases sans les couvrir de notions "compliquées".

Pourquoi Scala 3 ?

Scala 3 étant nouveau, on pourrait se dire qu'il serait plus judicieux d'apprendre Scala 2, plus matûre.

Cependant, Scala 3 est en rapide adoption (1014 bibliothèques en un an, soit un tier de Scala 2.13.x, avec un bon support des différents outils externes, build tools, IDEs, etc...). De plus, Scala 3 possède plusieurs fonctionnalités qui le rendent plus adapté pour l'apprentissage:

• Nouvelle syntaxe moins "bruyante" basée sur l'indentation
• Plus de "god keywords" (comme implicit cité plus haut)
• Des messages d'erreur plus précis
• Une volonté générale de rendre le langage plus "beginer-friendly"

Structure de la suite d'articles

Je ne suis pas encore tout à fait sûr de la structure exacte de cette série de cours. Pour l'instant, je compte me baser sur une structure similaire à celle de l'article de Daniel Ciocîrlan avec quelques changements toutefois:

• Prérequis
• Variables et types de données de base (nombre entier, flottant etc...)
• Conditions
• Boucles (while + for)
• Fonctions
• Collections (et probablement généricité)
• Plusieurs articles sur la POO
• Plusieurs articles sur la programmation fonctionnelle
• À voir plus tard

J'aimerais qu'au final on ait les tag suivant: "Nouvel article", "Amélioration", "Question" et "Meta"
ça impose de changer les templates, pour le moment leur "tag" utilise les "anciens" noms
et dans la même logique, ne plus préfixer les issues avec le tag, genre ne plus avoir [NOUVEL ARTICLE] huhu

copy/pasta de mes messages sur discord

Sujet de l'article

Sujet très inspiré de cet article dont le lien avait été posté sur le canal #langages-fonctionnels. Il traite de l'utilisation des free monads pour représenter un système de règles complexes (ici d'un jeu de cartes) qui peuvent être modifiées dynamiquement. Deux intérêts principaux:

• Faire un DSL restreint n'autorisant que les actions "valides"
• Pouvoir métaprogrammer l'action décrite par une composition de monades

Je trouve l'idée de l'article originale et prometteuse mais assez survolée. J'aimerais faire un article plus détaillé sur ce même principe en prenant comme exemple un système (très simplifié) de combat pokémon comprenant:

• Des pokémons (Espèce, PV, Vitesse...)
• Des capacités dont l'effet est représenté par des free monads (DSL)
• Des talents dont l'effet est décrit par une règle de réécriture du DSL (e.g Soin Poison transforme les dégâts du poison en soin)
• Des status comprenant deux effets: règle de réécriture à l'instar du talent (e.g la brûlure divise par deux les dégâts) et effet à la fin du tour (e.g le poison inflige des dégâts à chaque tour).

Je n'ai pas encore push le projet sur Github.

Langage

Je compte utiliser Scala car il s'agit du langage que je maîtrise le mieux et je pense que sa syntaxe est plus compréhensible pour la plupart des personnes que celle de Haskell ou OCaml.

Prérequis

L'article n'est pas destiné aux novices mais plutôt à ceux qui ont au moins les bases de la programmation fonctionnelle. Les notions d'ADT/enums fonctionnelles et pattern matching seront considérées comme connues. Je ne pense pas qu'il y ai spécialement besoin de savoir ce qu'est exactement une monade. J'en citerai quelques exemples (Option, List) puis j'expliquerai plutôt en détails ce qu'est une free monad (est-ce que quelqu'un a un équivalent français ?).

URL de l'article concerné

https://hub.notaname.fr/langages/python/comment-structurer-un-projet-python

À propos de cet article

Il faudrait dire que le "root project" est également le répertoire où il faut faire git-init

On pourrait mettre quelques classifiers en example avec entre autre "Private :: Do Not Upload"

J'aimerais proposer une réécriture plus nuancé de mon article python_exe.md.