Un zeste de Python

Tout le monde se secoue ! 

J’ai commencé (jeudi 19 avril 2018 à 22h28) la rédaction d’un tutoriel au doux nom de « Un zeste de Python » et j’ai pour objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limites pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme.

J’avais démarré le chantier en 2017, puis j’ai continué à y réfléchir, j’ai fait d’autres choses, et j’ai repris le sujet en début d’année (avec pour but de le terminer en 2020).

Tout n’est pas encore rédigé, loin de là, mais j’ouvre en bêta pour partager ce que j’ai actuellement et commencer à recueillir des retours. J’aimerais principalement des avis sur le fond, si vous trouvez que c’est clair, fluide, correct.

J’ai pour l’instant rédigé les chapitres des parties I (Premiers pas) à IV (Fonctions), à l’exception du chapitre sur l’installation et des TP qui ne sont abordés que brièvement. Les autres chapitres ne sont pas vides pour autant, ils contiennent simplement des listes à puce pour référencer les notions à aborder, donc n’hésitez pas à y jeter un œil et faire des retours aussi.

Pour la suite, j’aurai sûrement besoin d’un peu d’aide sur l’installation (captures d’écran Mac OS / Windows) mais je garde ça pour la fin, peut-être aussi pour des illustrations (si c’est pertinent). Faudra aussi que je refasse le logo mais pareil, c’est pas vraiment urgent.

Merci !

bonne initiative, merci !

Salut,

Je remarque que vous êtes plusieurs à utiliser le bouton « signaler une faute » pour faire des retours. Merci à vous, mais je ne trouve pas ça tellement pratique. Ça déclenche un nouveau MP à chaque signalement et c’est très difficile à suivre, de plus ce n’est pas accessible aux autres potentiels relecteurs.

Est-ce qu’il serait possible de plutôt profiter du sujet de la bêta pour grouper et remonter les différentes erreurs que vous pourriez constater ?

Merci encore.

Bonjour,

Suite à la recommandation d’#entwanne je bascule sur le forum, par contre comme j’ai ecris ce post au fil de la journées certaines remarques risquent de faire doublons

Dans le chapitre :Bloc conditionnel

if 2 == 2:
    print('> Nous sommes dans le bloc conditionnel')
    pront('> Ici encore')
print('Nous sommes en dehors du bloc')

le 2eme print est marqué pront

Dans l’introduction de TP : Ajoutons des conditions à notre jeu

2eme phrase in manque un n à "suivant les données saisies"

Dans le chapitre sur les listes

paragraphe Mutabilité

La phrase

"leur valeur ne pouvait pas changer une fois qu’elles avaient été définies." est troublante, elle commence au singulier et fini au pluriel.

parcourir des listes

L’exemple de programe calculer max , initialise max_number = 0, il ne serait pas préférable de faire max_number = numbers[0] ? (cas d’une liste composée de nombres négatifs)

Dans Retour sur les types de données , Principales méthodes des liste

Je pense qu’il serait bien de dire que la méthode copy ainsi que les autres techniques de copie présentées ne créent q’une copie au 1er niveau de la liste et que cela peut entraîner un comportement inattendu sur des listes imbriquées (je me suis fait avoir plusieurs fois avec ça )

chapitre sur les fonctions :

Paragraphe Paramètres de fonction

Dans la partie liées aux erreurs on a la phrase :

Une erreur survient s’il n’y a pas assez d’arguments pour compléter tous les paramètres.

qui est ok, par contre la phrase sur les paramètres en trop :

Au contraire, une autre erreur est levée s’il y a trop d’arguments par rapport au nombre de paramètres.

On devrait remplacer Au contraire par De même en effet dans les 2 cas une erreur est levée.

Paragraphe Plusieurs return dans une fonction

La liste de plan est toujours présente dans le paragraphe alors celui semble complètement rédigé.

Dans le paragraphe Unpacking

Il serait peut être intéressant de parler du splat * , pour des constructions du type a, *_, b = long_tuple ou c’est anticipé ?

Ok pour les fautes de frappe / concordance, je corrigerai ça.

Alors si, bien sûr, mais je m’étais dit que je voulais aller au plus simple pour juste présenter l’itération. Mais pourquoi pas, ça ne serait pas beaucoup plus compliqué avec une fonction valide.

J’étais persuadé d’avoir abordé le sujet mais en effet je ne retrouve rien. Donc oui c’est bien quelque chose que je veux expliciter.

Mon « au contraire » veut plutôt s’appliquer à la situation (trop d’arguments contrairement à trop peu). Je n’aime pas la formulation avec « de même », ça laisserait penser que c’est la même erreur.

Ouais j’ai quelques oublis comme ça. Je vérifierai pour être sûr de bien avoir rédigé tout ce que je voulais avant de retirer la liste.

Alors c’est prévu, mais plus tard. La section est prévue ici : https://zestedesavoir.com/contenus/beta/2514/un-zeste-de-python/7-aller-plus-loin/5-retour-sur-les-fonctions/#3–3-varargs

Il y aura aussi un lien vers https://zestedesavoir.com/articles/175/sortie-de-python-3–5/#2-principales-nouveautes.

(d’ailleurs il ne faut pas trop s’attarder sur le découpage actuel des chapitres / sections que je referai probablement par endroits parce que ce n’est pas toujours bien dosé).

Merci !

edit : Ce message n’a pas lieu d’être ><

Le tutoriel m’a l’air de se vouloir plus complet que le tutoriel qui était précédemment sur le site, est-ce qu’il a pour but de devenir un Big tuto à la manière de celui sur le C ou le C++ ?

En effet, le but est d’aborder tous les points nécessaires pour faire un programme Python, à l’exception de la programmation objet. Il a déjà la forme d’un big tuto.

Non je ne vous ai pas oubliés.

Moins de motivation que prévu donc ça m’a logiquement pris plus de temps, mais j’ai continué à avancer pas à pas.

J’ai effectué les corrections suite aux retours qui avaient été faits, et j’ai rédigé la partie 6 « Entrées / sorties ». Pas encore en totalité, vous verrez qu’il reste des listes à puces de notes, notamment sur la gestion des exceptions et sur le TP, je continue de travailler dessus.

Mais pour le moment, je vais attaquer la partie 7, qui me permettra ensuite d’avoir une vue d’ensemble du contenu.

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Bonjour,

Don’t Repeat your self!

Une petite typo

L’idée première, c’est d’éviter de se répéter, de du~~ b ~~ p liquer du code.

Renvoyer plusieurs valeurs

La fonction divmod devrait utiliser // au lieu de / pour avoir le même résultat que la fonction builtin.

>>> from math import pi
>>> 4//pi
1.0
>>> 4/pi
1.2732395447351628
>> divmod(4,pi)
(1.0, 0.8584073464102069)

Tu parles de la partie 5 alors ? Merci je corrigerai ça !

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Pour les nom de variables, tu écris :
autres caractères interdits
En fait, les autres caractères sont permis.

你好="bonjour"
print(你好)

Donne à l’exécution :

bonjour
>>> 

Mais il est recommandé d’utiliser les caractères du jeu ASCII.

Par ailleurs, l’utilisation du snake_style plutôt que du camelStyle est une question d’habitude du programmeur. La PEP8 ne prend pas parti.

Par ailleurs, l’utilisation du snake_style plutôt que du camelStyle est une question d’habitude du programmeur. La PEP8 ne prend pas parti.

Ici, ils conseillent le snake_case pour les noms de variable et de fonctions.

Je ne vois pas en quoi ça contredit mon point (que je n’ai d’ailleurs pas encore rédigé car ne voulais pas m’attarder sur ces détails pour le moment), « 你 » et « 好 » étant des lettres (catégorie unicode Lo).

Donc non, les autres caractères qui ne sont pas des chiffres (Nd), des lettres (Lu, Ll, Lt, Lm, Lo et Nl) potentiellement accentuées (Mn et Mc) ou des underscores (Pc) ne sont pas autorisés dans les noms.¹

La PEP8 prend clairement parti sur le sujet en faveur de la snake_case, je n’ai rien inventé.

En fait, les autres caractères sont permis.

你好="bonjour"
print(你好)

Donne à l’exécution :

bonjour
>>> 

Je ne vois pas en quoi ça contredit mon point (que je n’ai d’ailleurs pas encore rédigé car ne voulais pas m’attarder sur ces détails pour le moment), « 你 » et « 好 » étant des lettres (catégorie unicode Lo).

Donc non, les autres caractères qui ne sont pas des chiffres (Nd), des lettres (Lu, Ll, Lt, Lm, Lo et Nl) potentiellement accentuées (Mn et Mc) ou des underscores (Pc) ne sont pas autorisés dans les noms.¹

Et 7 exceptions en plus de ces catégories.

C’est juste qu’à la lecture du texte, je comprends qu’on n’a pas le droit de rédiger le code que j’ai fourni.

lettres minuscules, underscores, chiffres p(as en première position)
éviter les majuscules et les lettres accentuées
autres caractères interdits
noms réservés

Pourtant ce n’est pas ce que ça dit, mais encore une fois il s’agit d’une liste à puces et donc de paragraphes que je n’ai pas encore rédigés, le tout devrait être plus clair une fois finalisé.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Bonjour les agrumes !

La bêta a été mise à jour et décante sa pulpe à l’adresse suivante :

Merci d’avance pour vos commentaires.

Dans ton intro :
N’hésite pas à demander de l’aide si toutefois tu butterais sur un point ou serais bloqué sur un exercice.
Comme les SI n’aiment pas les RAI, il faut écrire :
N’hésite pas à demander de l’aide si toutefois tu buttais sur un point ou étais bloqué sur un exercice.

Je ne suis pas d’accord avec la règle (il y a des cas légitimes de si + rai dans les discours rapportés, « il m’a demandé si tu serais là »), mais effectivement je me suis planté dans la conjugaison ici, merci.

Edit : C’est corrigé.