Un zeste de Python

Débuter avec Python

a marqué ce sujet comme résolu.
Auteur du sujet

Tout le monde se secoue ! :D

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. ^^

Un zeste de Python.
Un zeste de Python.

Merci !

Édité par entwanne

Auteur du sujet

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é ?

+1 -0
Auteur du sujet

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

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)

kayou

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.

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 ^^ )

kayou

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.

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

kayou

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.

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

kayou

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.

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

kayou

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 !

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++ ?

+0 -0
Auteur du sujet

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.

Édité par entwanne

Auteur du sujet

Bonjour les agrumes !

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

Beaucoup de temps est encore passé, mais je continue d’avancer !

Depuis la dernière mise à jour, j’ai notamment travaillé sur la partie 7 (Aller plus loin), des chapitres 1 (Un peu d’aléatoire) à 5 (Retour sur les fonctions).

J’ai oublié de supprimer quelques listes à puces et des typos se sont forcément glissées dans certains mots, je corrigerai tout ça à la fin quand j’aurai terminé la rédaction. Pour le moment je cherche principalement des retours sur le flow, la manière dont sont abordées les notions, si le tout est correct et compréhensible.

Merci d’avance pour vos commentaires.

Édité par entwanne

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.

Édité par etherpin

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0

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. :)

Assez des salamis, je passe au jambon — Je fais un carnage si ce car nage car je nage, moi, Karnaj ! — Le comble pour un professeur de mathématique ? Mourir dans l’exercice de ses fonctions.

+0 -0
Auteur du sujet

En fait, les autres caractères sont permis.

你好="bonjour"
print(你好)

Donne à l’exécution :

bonjour
>>> 

etherpin

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.1

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.

etherpin

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

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Variable names follow the same convention as function names.

mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.

PEP8

Édité par entwanne

En fait, les autres caractères sont permis.

你好="bonjour"
print(你好)

Donne à l’exécution :

bonjour
>>> 

etherpin

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.1

Et 7 exceptions en plus de ces catégories.

Source: PEP8

entwanne

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

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte