Découvrir la programmation avec Python

Bonjour

J'aimerais avoir vos retours sur ce tutoriel (très long), son contenu, sa structuration, sa présentation.

Le logo est en attente.

Merci de vos remarques et de votre retour !

Sachant qu’il y a déjà deux cours d’introduction à Python sur le site, qu’est-ce que le tien apporterait de plus / différent ?

Il est beaucoup plus détaillé, contient (beaucoup) d'exercices, il vise un public plus large, ceux qui sont amenés à utiliser Python dans un cadre scolaire ou universitaire sans être de futurs informaticiens/programmeurs.

C'est sûr que le côté pratique a l'air intéressant, mais c'est aussi vrai qu'il y a aussi d'autres contenus introduisant Python comme mentionné par Dominus Carnufex. M'enfin, ces deux ne sont pas encore terminés et si tel est ton souhait, je ne peux que t'encourager à continuer dans ta voie.

Sinon, j'ai jeté un coup d’œil au plan et je vois que tu parles de Turtle. Savais-tu qu'il y a déjà un tutoriel ici même ? Après, j'aime bien les exercices que tu proposes, donc si jamais n'hésite pas à les partager ici

Pour les notes de bas de page, il faut ajouter : entre le nom et le contenu de la note, pour que ça fonctionne (cf ton intro), ex : [^AI]: cf. la bibliothèque TensorFlow.

Bonjour Smokiev

Bien sûr que j'ai vu ton tutoriel très complet, une très bonne référence, et d'ailleurs je le cite dans mon tuto, ICI.

Concernant les notes de bas de page, j'ai en effet oublié les deux-points, je vais rectifier, merci.

Pour ce qui est de ta proposition de partage d'exercices, c'est très volontiers que je placerai dans le lien que tu donnes les quelques exercices de Turtle dont je dispose mais attention, ils sont élémentaires !!

Après lecture de ce cours, qui me paraît très bon pour l'apprentissage de la programmation, j'ai tiqué sur quelques points concernant le langage.

Premièrement, j'ai un peu de mal avec l'utilisation d'un interpréteur au sein du navigateur (surtout que tu dois en manipuler deux différents le long du cours), mais soit.

Pour être plus précis, le saut de fin de ligne n'est utilisé que si l'affichage est suivi d'un autre affichage.

Je n'ai pas compris cette phrase à propos de print. Pour moi, le caractère de fin de ligne est imprimé à chaque fin de ligne, qu'elle soit suivie d'un nouvel affichage ou pas.

De même, pour simuler un dé, on utilisera randrange(6)

Que tu utilises dans l'expression 1 + randrange(6). randrange me semble inadapté à ce cas, on lui préférera un randint(1, 6) par exemple, qui spécifie bien les bornes et ne nécessite pas de post-calcul.

La syntaxe x += a est équivalente à x = x + a

Ça me gêne de voir cela présenté comme une vérité générale. C'est vrai tant que tu manipules des nombres, mais ça ne le serait plus avec des listes, où les deux instructions prennent un sens un peu différent.

Plus loin, tu parles d'éléments de syntaxe (boucles while et for) sans les avoir introduites, j'ai trouvé ça un peu étrange, sachant qu'elles n'arrivent dans le cours que bien plus tard.

Au moment des boucles, justement, le pas de la fonction range mériterait d'être expliqué. Tu en viens à présenter des codes un peu étranges pour passer outre (lors des comptages de 42 en 42, de 5 en 5).

Par exemple, étant donné une liste L de nombres, si on cherche à déterminer combien L contient d'entiers positifs, on utilisera une boucle d'en-tête du type for i in range(len(L)).

Je suis en total désaccord avec cette proposition, et avec la majorité des boucles for que tu utilises pour illustrer ton cours. L'index i est bien souvent inutile, il n'est pas nécessaire de le connaître lors des itérations (et même s'il l'était, il y a d'autres manières de faire).

Cette boucle devrait être remplacée par une du type for element in L, plus simple à lire et plus en accord avec le langage.

Ligne 5 : à chaque tour de boucle, l'appel len(L) est recalculé alors que len(L) est un nombre qui ne varie pas.

Certes, l'appel est répété, mais son résultat n'est pas recalculé. Python se charge déjà de stocker la taille pour éviter de la recalculer à chaque appel.

Aussi, la plupart des boucles while utilisées pourraient être remplacées par un for et un break judicieux (qui ne nécessiterait pas de revenir en arrière sur l'index comme dans l'exercice sur les puissances de 1.0001).

JOURS_SEMAINES = ["toto", "lundi", "mardi", "mercredi", "jeudi", "vendredi", "samedi", "dimanche"]"

J'ai trouvé cet exemple bizarre. Sémantiquement, le tableau est censé contenir les noms des jours de la semaine, ce n'est pas le cas à cause de "toto". Je comprends bien la raison de sa présence, mais ça me semble être une réponse incongrue à un problème assez simple.

Voilà pour ce qui est de la lecture. Maintenant j'ai d'autres interrogations sur le cours en lui-même et sur la possibilité de l'intégrer à la collection de tutoriels Python.

• Si je comprends bien c'est un cours que tu donnes déjà à l'extérieur, donc hormis quelques problèmes de mise en page, il est dans son état final. Est-ce que tu penses ajouter d'autres parties dédiées à des manipulations plus poussées du langage (traitement de chaînes, structures de données, communication, modules, etc.) ?
• Sinon, est-ce que tu vois un moyen de faire un pont entre ce tutoriel et les autre contenus en rapport avec Python ?

Merci.

Bonjour Etwanne

Pour être plus précis, le saut de fin de ligne n'est utilisé que si l'affichage est suivi d'un autre affichage.

Je n'ai pas compris cette phrase à propos de print. Pour moi, le caractère de fin de ligne est imprimé à chaque fin de ligne, qu'elle soit suivie d'un nouvel affichage ou pas.

Oui, c'est exact, je voulais dire autre chose, je changerai.

De même, pour simuler un dé, on utilisera randrange(6)

Que tu utilises dans l'expression 1 + randrange(6). randrange me semble inadapté à ce cas, on lui préférera un randint(1, 6) par exemple, qui spécifie bien les bornes et ne nécessite pas de post-calcul.

Je suis bien d'accord mais ça évite d'apprendre une nouvelle fonction pour si peu. On peut mettre une note de bas de page

La syntaxe x += a est équivalente à x = x + a

Ça me gêne de voir cela présenté comme une vérité générale. C'est vrai tant que tu manipules des nombres, mais ça ne le serait plus avec des listes, où les deux instructions prennent un sens un peu différent.

Nous sommes d'accord. Je nuancerai

Plus loin, tu parles d'éléments de syntaxe (boucles while et for) sans les avoir introduites, j'ai trouvé ça un peu étrange, sachant qu'elles n'arrivent dans le cours que bien plus tard.

Oui c'est vrai, à retirer.

Au moment des boucles, justement, le pas de la fonction range mériterait d'être expliqué. Tu en viens à présenter des codes un peu étranges pour passer outre (lors des comptages de 42 en 42, de 5 en 5).

C'est ce nous faisions dans les premières versions du cours mais pareil c'est une facilité «pythonique» et ce n'est pas un cours de Python.

Par exemple, étant donné une liste L de nombres, si on cherche à déterminer combien L contient d'entiers positifs, on utilisera une boucle d'en-tête du type for i in range(len(L)).

Je suis en total désaccord avec cette proposition, et avec la majorité des boucles for que tu utilises pour illustrer ton cours. L'index i est bien souvent inutile, il n'est pas nécessaire de le connaître lors des itérations (et même s'il l'était, il y a d'autres manières de faire).

Je me doutais un peu de ce genre d'opposition et j'avais mis une note de bas de page pour prévenir …

J'insiste : ce n'est pas un cours de Python et je n'ai pas envie d'introduire for z in it ni for _ in it ni for i, x in iterate(it) (cela a été tenté dans des versions précédentes du cours).

Cette boucle devrait être remplacée par une du type for element in L, plus simple à lire et plus en accord avec le langage.

oui, la façon pythonnique.

Ligne 5 : à chaque tour de boucle, l'appel len(L) est recalculé alors que len(L) est un nombre qui ne varie pas.

Certes, l'appel est répété, mais son résultat n'est pas recalculé. Python se charge déjà de stocker la taille pour éviter de la recalculer à chaque appel.

Je peux retirer la remarque qui effectivement est too much dans ce cadre. Cependant, l'appel a un coût, non négligeable (j'obtiens 20% de pénalisation en gardant len sur une liste de 1 million d'objets).

Aussi, la plupart des boucles while utilisées pourraient être remplacées par un for et un break judicieux (qui ne nécessiterait pas de revenir en arrière sur l'index comme dans l'exercice sur les puissances de 1.0001).

Idem pour break qui n'est pas introduit dans le cours.

JOURS_SEMAINES = ["toto", "lundi", "mardi", "mercredi", "jeudi", "vendredi", "samedi", "dimanche"]"

J'ai trouvé cet exemple bizarre. Sémantiquement, le tableau est censé contenir les noms des jours de la semaine, ce n'est pas le cas à cause de "toto". Je comprends bien la raison de sa présence, mais ça me semble être une réponse incongrue à un problème assez simple.

Tu préfères JOURS_SEMAINES = ["lundi", "mardi", "mercredi", "jeudi", "vendredi", "samedi", "dimanche"]?

---

Voilà pour ce qui est de la lecture. Maintenant j'ai d'autres interrogations sur le cours en lui-même et sur la possibilité de l'intégrer à la collection de tutoriels Python.

Comprends pas très bien le sens de cette interrogation.

• Si je comprends bien c'est un cours que tu donnes déjà à l'extérieur, donc hormis quelques problèmes de mise en page, il est dans son état final.
  Est-ce que tu penses ajouter d'autres parties dédiées à des manipulations plus poussées du langage (traitement de chaînes, structures de données, communication, modules, etc.) ?

Pourquoi pas ? Et merci du feedback

Je ne comprends pas le parti pris "c'est un cours de programmation en Python mais pas un cours de Python". En fait je ne vois pas l'intérêt d'enseigner des pratiques dont on sait qu'elles sont mauvaises si l'equivalent idiomatique n'est pas plus compliqué.

La forme un peu bâtarde avec la boucle for est symptomatique : d'un côté tu places des notes et des remarques sur l'appel à len() à chaque itération d'une boucle, de l'autre tu itères sur des indices au lieu des éléments en imposant une indirection superflue et en passant sous silence le fait que l'accès aux éléments de la liste en ma_liste[i] coûte non seulement deux instructions supplémentaires à la machine virtuelle à chaque itération, mais augmente également la possibilité de faire des erreurs.

Je ne vois pas le bénéfice que tu comptes tirer de ce choix.

Je rejoins l'avis de nohar. Je comprends l'orientation de ton tutoriel et le fait de ne pas vouloir t'encombrer de détails du langage, mais enseigner des mauvaises pratiques avérées me pose problème.

Pour ce qui est des jours de la semaine, je pensais effectivement à un tableau qui contiendrait les 7 noms, et rien d'autre.

Quant à la fin de mon message, ça concerne une idée de créer un fil conducteur entre les contenus Python, une certaine cohérence entre les cours, afin de pouvoir élaborer des parcours d'apprentissage (par exemple, quelqu'un voulant construire son site avec Django sera dirigé vers un cours d'apprentissage du Python, puis de la programmation objet en Python, et enfin sur un tutoriel Django).

Maintenant j'ai d'autres interrogations sur le cours en lui-même et sur la possibilité de l'intégrer à la collection de tutoriels Python.

Comprends pas très bien le sens de cette interrogation.

Comme je n’ai aucun intérêt personnel dans un quelconque contenu lié à Python, je peux me permettre d’expliquer les choses plus clairement et moins diplomatiquement.

En gros, ça fait maintenant plus d’un an (au moins depuis mai 2015) qu’on se casse le c** à essayer d’intégrer un petit peu de cohérence dans les contenus publiés sur le site, en particulier en essayant d’éviter les doublons, en se répartissant les tâches, en faisant des parcours structurés d’un contenu à un autre, etc.

Jusqu’à présent, l’expérience la plus concluante sur cette voie est la collection de tutos Python, lancée par nohar, qui est en bonne voie de parvenir à créer un parcours cohérent. Du coup, même si ma position ne présume ni ne présage en rien de ce qu’en pensera la validation, cela fait nécessairement un peu grincer des dents de te voir débarquer avec tes gros sabots et marcher sur les belles rangées de fleurs bien droites…

Par consquent, on se demandait si tu comptais recadrer ton cours de manière à ce qu’il puisse s’intégrer dans la logique générale des contenus Python du site, ou pas du tout.

@Dominus: Ton dernier message manque cruellement de diplomatie à mes yeux. Pascal Ortiz a fait l'effort de rédiger un cours complet et a la gentillesse de nous le proposer, la moindre des choses est peut-être de respecter le travail accompli, même si je partage ton avis dans les grandes lignes.

Je suis très dubitatif vis-à-vis de ce tuto.

Ce sera un peu en vrac, je lis le tuto en diagonale,

Ce cours est basé sur un cours d'introduction à la programmation donné par l'auteur depuis plusieurs années à l'Institut national universitaire Champollion. C'est donc un cours éprouvé.

Nous avons tous eu des cours suffisamment merdiques pour savoir que ce n'est pas parce qu'un cours est donné qu'il est de qualité ou éprouvé.

un type correspond à une catégorie d'objets (entiers, nombres réels, valeurs logiques, etc).

Nombre à virgule flottante, pas réel. On ne peut pas représenter $\pi$. On peut représenter 54 ou $\frac{3}{5}$.

Par exemple, en mathématiques, on écrit couramment

$$\frac{a}{bc}.$$

En Python, cela NE se traduit PAS par a / b * c mais par a /(b * c)

En maths non plus. Priorité des opérateurs, a / b * c signifie (a/b)*c, car pas de parenthèse.

Lorsqu'on effectue un ensemble d'opérations arithmétiques qui font intervenir des entiers et des flottants, le résultat est de type flottant :

Ce genre de phrase me semble complètement contradictoire avec le fait d'apprendre la programmation avec python plutôt que en python. Car selon les langages, ce sera différent.

Règle fondamentale : on n'utilise jamais l'opérateur == pour comparer deux flottants.

Personnellement, je n'aime pas du tout quand les trucs tombent de nul part comme ça…

Par exemple, la division entière de 474 par 8 admet 59 pour quotient et 2 pour reste. Attention ! ne pas écrire 4748

Plutôt que « ne pas écrire », donne les notations $474 \div 8 = 59$ et $474 \% 8 = 2$.

Plus d'affichage

Le chapitre entier est un condensé des mauvaises pratiques d'affichage, tous langages confondus…

Le caractère # porte différents noms : dièse, sharp, « pound », « hash » ; le terme français correct semblerait être « croisillon »

Non. Dièse (sharp en anglais) : ♯. Croisillon (pound) : #. Deux symboles différents.

Dans le hasard, tu utilises randrange(1, 50) puis tu fais randrange(6)+1 pour le dé. Pas logique.

J’arrête la lecture ici. Le cours me semble justement très loin d'être éprouvé. Il y a beaucoup de choses imprécises voire fausses.

Le rythme pose aussi problème. Tu mets vraiment vraiment beaucoup de temps avant de parler programmation. La mise en place de l'environnement est très longue. Même une fois en place, la première partie, là encore extrêmement longue, ne permet pas de faire quoique ce soit de plus qu'une calculatrice à la fin. C'est courant dans les tutos, mais là, cette partie a le gros défaut d'être très longue. Finalement, en 3 heures de temps, on sait faire une division euclidienne au mieux…

En gros, ça fait maintenant plus d’un an (au moins depuis mai 2015) qu’on se casse le c** à essayer d’intégrer un petit peu de cohérence dans les contenus publiés sur le site, en particulier en essayant d’éviter les doublons, en se répartissant les tâches, en faisant des parcours structurés d’un contenu à un autre, etc.

Je ne peux qu'approuver. Re-écrire des trucs sur Turtle, écrire un troisième tuto sur les bases de python, ignorer la présence d'un tuto de programmation tout-langage, c'est oublié l'écosystème ZdS. Je trouve ça très bête.

Je vois que beaucoup d'entre vous sont gênés par la tournure for i in range(len(L)) ce qui après tout peut se comprendre si une ligne éditoriale a été fixée sur votre site voulant promouvoir les bonnes pratiques du langage.

Je vais essayer d'adapter le document avec for element in liste et for i, element in enumerate(L) même si je trouve que cela complexifie la pratique des parcours de liste.

S'il y a d'autres points importants à examiner veuillez me les indiquer.

Je suis d'accord avec cette partie du message, pas forcément avec ce qui précède.

La collection de cours dont je parle manque d'un cours d'introduction au langage (l'actuel étant incomplet et pas tellement satisfaisant). Le constat est que le cours de pascal.ortiz existe déjà et pourrait être utilisé comme tel. Sauf que d'autres choses avaient été imaginées pour ce cours, notamment une exploration plus en profondeur du langage.

La question serait maintenant de savoir si le cours de pascal.ortiz peut devenir le tuto d'introduction que nous attendions, et comment se passe la suite si tel est le cas (puisqu'il couvre moins de concepts que prévu) :

• Compléter le cours pour lui faire faire un tour complet des éléments de syntaxe du langage ;
• Débuter un autre cours, qui se placerait à la suite de celui-ci, qui s'adresserait donc à un lecteur connaissant les bases de la programmation et de la syntaxe du langage, et qui apprendrait à manipuler le Python.

D'ailleurs, dans cette optique (intégrer la collection de tutos Python), je dois préciser que ce présent cours a quelques bons arguments.

Contrairement à une foultitude d'autres cours d'intro à Python, il donne de très bonnes définitions pour les notions de base comme objet ou variable, et c'est clairement à son crédit à mes yeux (c'est le point principal qui m'avait motivé à entammer la rédaction de mon propre cours, perso). Je suis sûr qu'avec un peu de travail d'adaptation, on pourrait l'inscrire facilement dans le parcours existant, et gagner beaucoup de temps.

L'approche n°2 d'entwanne ci-dessus est pas mal non plus : donner un premier contact en utilisant un interpréteur online pour goûter au langage (bref, le présent tuto), avant de passer à un tuto plus classique qui explique notamment comment CPython interprète les programmes n'est pas déconnant.

Mon cours est une sensibilisation à la programmation par la pratique et par l'exemple, avec toutes les limitations inhérentes à ce type de présentation. Il a assez peu d'ambition du point de vue de la programmation et encore moins concernant la connaissance du langage Python, c'est juste pour se lancer, ne pas effrayer le novice qui peut-être ne fera jamais plus de programmation après.

A priori, ma prochaine «obligation» (début 2017) est la rédaction d'un document assez détaillé sur Tkinter pour un public d'informaticiens. Il pourrait y avoir aussi un document assez détaillé sur les expressions régulières (et aussi sur les formatages de chaînes, ancienne et nouvelle versions). Je ne sais pas si ça peut vous intéresser.

Tout nous intéresse !

L'avantage serait aussi que ça rendrait ce second tuto plus simple à rédiger, sans s'attarder sur les éléments de syntaxe, et sans redite des concepts fondamentaux. On se rapprocherait peut-être plus d'une documentation très détaillée des structures du langage, et de quelques modules.

Je suis d'accord. L'approche serait grandement allégée.