PyCon France (PyConFR) est une conférence qui a lieu chaque année (sauf circonstances exceptionnelles) en France. Cette année, elle a eu lieu du 30 octobre au 2 novembre à Lyon, rassemblant des personnes de la communauté Python. Les participantes et participants à la conférence sont tenues de respecter le Code de Conduite de l’Association Francophone Python, l’association qui organise l’événement.
Le but de ce document est d’améliorer l’accueil et la sécurité des participantes et participants ainsi que de donner aux organisateurs et organisatrices des indicateurs sur le comportement de la communauté. En effet, pour pouvoir entendre, il faut pouvoir écouter. C’est maintenant devenu une pratique courante, pour les organisations ayant un Code de Conduite, de publier un rapport de transparence suite à la tenue d’une conférence. C’est le but de ce document.
(Remplacez ce paragraphe par une courte description de votre nouvelle catégorie. Cette information apparaîtra dans la zone de sélection de la catégorie, veillez donc à saisir moins de 200 caractères.)
Utilisez les paragraphes suivants pour une plus longue description ou pour établir des règles :
À quoi sert cette catégorie ? Pourquoi les utilisateurs choisiraient-ils cette catégorie pour leur discussion ?
En quoi est-elle différente des autres catégories existantes ?
Quels sont les sujets qui devraient figurer dans cette catégorie ?
Avons-nous besoin de cette catégorie ? Devrions-nous fusionner celle-ci avec une autre catégorie ?
J'ai depuis quelques semaines le bonheur de suivre quelques devs débutants, ou aspirants devs. Je lis donc du code généré, ma joie est grande. Je profite de ce vendredi pour partager avec vous mes impressions. L'incubateur d'excellence qu'est DLFP aura, si je suis chanceux, d'autres retours d'expérience à partager.
C'est propre.
Plus propre que du code humain. Trop propre. Ce que tu gagnes en lisibilité, tu le perds en concision, en expressivité et en sens. Au fond, rien ne change. Le code décrit le comment, alors que ce qui m'intéresse reste le pourquoi.
Il n'y a évidemment pas de tests. Rien à voir avec la génération. De toute façon il faudra tout reprendre pour intégrer un vrai dispositif de tests, condition nécessaire pour que je fasse confiance au programme.
Le code généré se repère immédiatement: fonctions bien nommées, formatage impeccable, docstrings qui brillent, noms de variables trop précis, aucune variable a, b, x, tmp, out, typage strict des entrées et sorties etc. Un niveau de détail souvent trop fin, l'inverse d'un code en cours d'écriture.
Cette forme parfaite est trompeuse.
Tu crois que le code fait le travail. Peut-être au niveau micro, les fonctions sont surement correctes. Au niveau macro, macache. Alors comment être sûr que ce code fait ce qu'il annonce ? En découplant les fonctions et en le disséquant pièce par pièce.
C'est certes plus agréable à lire, mais tu perds un indicateur essentiel. La maturité disparaît. La forme est standardisée. Il n'y a plus de code smell, plus de style, plus de rugosité. Comment juger du fond uniquement à la lecture ?
Certains codes écrits n'importe comment se repèrent au premier coup d'œil. C'est une alerte. Pas de structure, fonctions fleuves de 100 lignes, pas de séparation fond/forme. Un brouillon intégral. Et les brouillons doivent être réécrits.
Le même code, rédigé proprement, structuré, soigné, fera tout aussi n'importe quoi donnera l'impression que c'est pensé. L'impression d'une intention, de la crasse propre.
De la crasse propre ?
Oui mais c'est trolldi, alors je vous en prie.
Avec le code généré, tu perds la possibilité de juger sur l'apparence. Plus de style, plus de subtilités, plus de petites variables piégées. Si tout est bien nommé, comment repérer ce qui compte vraiment ?
Avec ce code aseptisé, je vais peut-être perdre du temps.
Ou pas.
Débutant sur python je viens de commencer à prendre en main un éditeur de code, en l’occurrence IDLE (avant ça je codais via le terminal lol) et je rencontre un problème depuis quelque temps quand j’enregistre (en .py) mon code et que j’ouvre le fichier pour qu’il s’exécute celui-ci s’ouvre sur une fenêtre puis disparaît instantanément. Si quelqu’un pourrait m’aider merci d’avance
Meetup de fin d’année le jeudi 18 décembre, dans les locaux de Lowit (métro Part-Dieu) !
Comme l’an dernier, on vous propose un format Lightning Talks
Si vous souhaitez parler de quelque chose, d’une bibliothèque, d’un outil, d’un projet… N’hésitez pas à me contacter pour que je rajoute sur la liste des sujets
Skull King est un jeu de plis sur un thème de pirates, existant depuis plusieurs années en diverses versions.
Présentation rapide du jeu
Plusieurs cartes et effets ont été ajoutés au fil des éditions. Par exemple, une version éditée par Schmidt contient 66 cartes (cartes de couleurs allant de 1 à 13, fuites, pirates, sirènes, Scary Mary et Skull King). La version Grandpa Beck/Blackrock games fournit en plus les baleines, le Kraken, deux cartes butin, une valeur supplémentaire par couleur (le 14) et un effet différent par pirate.
Pour une présentation complète, les règles sont disponibles en ligne, sur de nombreux sites : par exemple en texte ou en vidéo. Pas la peine de s’étendre plus, allez les consulter pour avoir une idée des règles du jeu.
La boîte éditée par Schmidt :
La boîte éditée par Blackrock :
En flèches et en couleurs
Puisque vous avez maintenant une idée de l’ordre de priorité entre les cartes (n’est-ce pas ?), vous allez comprendre aisément les graphes orientés suivants.
Au moins une carte baleine a été jouée :
Ce premier cas est le plus courant lors d’une partie.
Aucune carte baleine n’a été jouée :
Évidemment, ce cas ne peut arriver que dans une édition paquet de cartes contenant les sirènes.
Code Source des graphes
Les deux graphes ont été réalisés avec le vénérable graphviz (version 2.42.4 mais beaucoup de versions plus anciennes devraient produire le même résultat).
Cet article explore pourquoi Python est un excellent choix pour l’écriture de scripts, en abordant les défis rencontrés avec d’autres outils qui peuvent se comporter différemment selon les machines ou ne pas être toujours installés. Une perspective pratique sur l’utilisation de Python comme solution de scripting fiable et cohérente.
Un avis sur la certification Python de CodinGame ?
D’après le site, on peut retenter la certification tous les mois si on a un score qui ne nous satisfait pas.