Apprendre à programmer avec Python 3

Bonjour à tous,

J'ai commencé (il y a 2 semaines, 3 jours) la rédaction d'un tutoriel dont l'intitulé est Apprendre à programmer avec Python 3.

J'aimerais obtenir un maximum de retour sur celui-ci, sur le fond ainsi que sur la forme, afin de proposer en validation un texte de qualité.

Si vous êtes intéressé, cliquez ci-dessous

Merci d'avance pour votre aide

Petite notes persos dans ce message automatique :

J'active la beta pour avoir des premiers retours assez tôt dans l'écriture dans ce tuto. Il y a surement des fautes qui trainent mais je dois avouer que dans un premier temps, je me consacre d'abord à l'aspect structure/contenu.

Par rapport à l'autre cours, j'ai l'impression, peut être fausse, d'un certains enlisement. C'est pourquoi je propose une version alternative.

Toute aide est la bienvenue.

Par rapport à l'autre cours, j'ai l'impression, peut être fausse, d'un certains enlisement. C'est pourquoi je propose une version alternative.

Tu veux dire que l'autre projet de cours n'est pas très actif ? Ou alors que c'est son contenu qui ne te convient pas ?

Sinon, je ne suis pas sûr qu'il soit judicieux de rassembler while et for. Certes, ce sont des boucles, mais l'une se base sur une condition, alors que l'autre parcourt un itérable. C'est très différent et je pense que la seconde devrait être abordée en même temps que la notion de collection, comme nohar prévoit de le faire.

Peut-être un peu les deux. L'idée de l'apprenti sorcier est bonne mais j'ai peur que certains ne prennent pas le cours au sérieux. Je suis prêt à convertir le chapitre fonction à une forme plus proche du reste du tuto maintenant que j’ai posé le gros du contenu. Mais ce n'est pas ma principale motivation. Je trouve que le dépôt GitHub est un peu au point mort, ce qui est le point qui me chagrine le plus. Après, comme je l'ai dit, ce n'est qu'un avis personnel peut être erroné.

Edit : Je viens de voir ton edit. Je doit avoué que j'ai mis la boucle for plus par volonté de ne pas faire un chapitre que sur while (ce qui, en soit, n'est peu-être pas aussi dérangeant que le pensais). Comme tu le suggère, je déplacerait avec plaisir for dans le chapitre sur les listes où il sera moins seul. Ce qui m'inquiète du coup est le pauvre while solitaire, mais après tout, pourquoi pas.

Dans tous les cas il n'y a pas de problèmes pour avoir deux tuto sur le meme sujet.

+1 pour le fantôme.

@martinqt : nohar projette d'introduire la boucle while dans le chapitre sur les conditions, ce qui me semble particulièrement judicieux. En effet, il s'agit juste de faire une action tant qu'une condition est vérifiée et non pas uniquement si une condition est vérifiée.

Bonjour à tous !

La bêta du tutoriel a été mise à jour.

Merci pour vos relectures

• Modification de la structure suite aux retours (boucles, exceptions)

J'approche doucement de la fin de la partie 1, plus que le chapitre des modules à finir. Je pense que la structure de la première partie est stabilisée, je vais donc commencer la relecture de cette dernière.

Tous retours sont les bienvenus.

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures.

Je prévois d'envoyer la première partie en validation d'ici peu (j'ai vu que ça s'était fait sur d'autres tuto). Le seul petit problème est la partie installation avec Mac et Linux (j'ai ajouté un paragraphe pour ce dernier, mais ne maitrisant pas Linux, je préfère me méfier) et la partie fichier pour les deux mêmes OS.

Si quelqu'un se sent de rédiger, ou de me donner les étapes clés de l’installation, je suis preneur. Sinon, est-ce envisageable d’envoyer la validation avec seulement les parties Windows et d’ajouter les autres OS dans une version ultérieure ?

Merci par avance.

Tu as bien avancé ! J'ai survolé très rapidement le contenu, et dans ton premier TP, il y a une petite coquille :

Pour rappel, un angle peut, par exemple, être exprimer exprimé

Bon courage pour la suite de la rédaction !

Merci pour la coquille, maintenant corrigée sur le brouillon.

Je vais un peu attendre les retours et voir si je lance la validation de la première partie avant de commencer la rédaction de la deuxième.

Bonsoir

Au tout début,

Tous les programmes, de l'éditeur de texte le plus basique au programme de simulation 3D de la NASA est traité

Sont traités, puisqu'il s'agit de "tous les programmes" ?

Juste après,

Il existe différents niveau de langages.

niveaux

Juste en dessous encore,

Les langages haut niveau, comme Python, permettent de communiquer avec l'ordinateur à un niveau plus élevé et de cacher les opérations élémentaires effectuées par l'ordinateur.

Je trouve pas la phrase très claire, "à un niveau plus élevé", c'est pas très facile à comprendre. Je pense que tu devrais la reformuler Et du coup, même chose pour les bas niveau juste après.

celui des langages de haut niveau et qu'ils sont généralement plus simples à manier.

est, il s'agit du verbe ici

Bon en un paragraphe il y a déjà beaucoup de fautes, alors je pense qu'il vaudrait mieux que tu fasses appel à un correcteur (j'ai vu que tu en cherchais justement un dans aider les auteurs, du coup je t'ai envoyé un mp…) avant de lancer en validation la partie une, et puis ça te laissera un peu de temps pour rédiger la suite

En dehors de nos amies les fautes, le tutoriel est très bien écrit, tu abordes tout en douceur et c'est pédagogue dans l'ensemble.

Bon courage de ma part aussi !

Je viens de lire une partie du chapitre 3, portant sur les variables. Voici une petite liste de coquilles/conseils :

Dans l'introduction,

Mais nos résultats

Dans la présentation,

comme un ensemble de tiroirs, chaque un chacun ayant une étiquette et un contenu

Quand tu indiques les règles à suivre pour nommer ses variables, peut-être que le vouvoiement serait plus approprié ? (Personnellement, ça ne me dérange pas, mais ce ne sera sûrement pas le cas de tout le monde. De plus, tu vouvoies le lecteur par la suite, ce serait plus cohérent.). Ensuite :

Tes noms de variable peuvent contenir _ (un « underscore ») mais pas d'autres caractères spéciaux (accents compris).

De manière générale, préférez des noms de variables clairs et évocateurs, et pas trop longs.

PS : Il est tout à fait possible que je me sois trompé !

Salut, alors les fautes ont étés corrigées mais la bêta n'a simplement pas été mise à jour Merci d'avoir signalé les fautes

Hugh'
Bon, heureusement que je n'ai pas lu tout le tutoriel

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

Alors j'ai prit le temps de commencer une relecture, voici quelques commentaires. Globalement surtout des remarques mais j'ai repéré quelques erreurs de codes ou des choses fausses (je ne sais pas d'où tu tiens ton triple égale en python).

• Présentation:

  • On peut par exemple citer l'Assembleur comme exemple de langage bas niveau.

    C'est un assez mauvais exemple je pense car déjà il n'y a pas UN langage assembleur mais DES langages (un par type de processeur), ce n'est pas standardisé et enfin par ce que ce n'est qu'une transcription textuelle du langage machine. Le C serait probablement un meilleur représantant.

  • Le principal avantage des langages bas niveau est qu’ils sont plus rapides, celui des langages de haut niveau est qu'ils sont généralement plus simples à manier.

    En soit la rapidité d'un langage bas niveau est plus souvent une conséquence qu'une vérité général. Un programme bien fait dans un langage haut niveau peut être plus rapide qu'un programme moyen dans un langage bas niveau. La principale différence est qu'avec un langage bas niveau tu as un accès direct aux ressources de la machine (en particulier de la mémoire). Cet acces direct te permet de mieux tirer parti du matériel sans couche intermédiaire ce qui peut facilement apporter des gains de performances mais la vitesse est plus une conséquence qu'une vérité intrinseque.

  • Après ce suspens intense, voici la réponse à votre question : interprété. Ah oui, et la question était bien sûr, dans quelle catégorie se trouve Python . Maintenant que l'on y voit un peu plus clair, passons à l'installation.

    Techniquement Python est les deux. Il y a systématiquement (au moins dans CPython, c'est dépendant de l'interpréteur ça) une compilation vers du byte-code. Certe ce n'est pas une compilation vers le langage machine mais vers un byte code plus haut niveau mais il y a bien compilation. Et ce byte-code est interprété. Donc déjà ça me gene de parler d'interprétation pur. Ensuite le soucis est que ce n'est pas le langage qui est interprété ou compilé mais l'implémentation. En dehors de CPython, PyPy fait une compilation à la volée (donc en pratique il compile bien vers du langage machine), JPython compile vers le byte code de la JVM, IronPython vers celui de la CLR.net, Cython fait une "vrai" compilation en générant du C. Bref pour un même script tu peux tout avoir. Il serait bon de préciser que tu parle bien de CPython là (et encore, cf ma remarque sur le bytecode).

  • Installation

    Pour te faciliter la vie, tu devrais fixer un numéro de version mineur. Entre Python 3.0 et Python 3.4 il y a eu énormément de différence a plusieurs niveaux. Si l'utilisateur a Python 3.2 tu ne pourra pas parler de yield from sans qu'il ai des soucis. Si il a le 3.3 tu ne pourra pas parler de enum ou asyncio. Si le lecteur lit apres semptembre et qu'il a la 3.5, il aura des warning si il essait de faire une variable nommé async ou await et il aura un opérateur binaire de plus. Bref pour ta tranquilité, tu devrais vraiment fixer la version. "Nous travaillerons avec Python 3.4" + dire que les autres versions proches ont assez peu de différences mais que tu ne garanti pas que tout marche pareil.

• Première approche:

  • Pour les editeurs sous Linux, tous ceux fournit de base supportent la coloration syntaxique. Sous Ubuntu Unity ou gnome, il y a gedit de disponible. Kate sous Kde.
  • De façon général les "à venir" donne une impression de "non terminé" pas terrible pour la publication. Vire carrément les explications sur Mac si tu en dispose pas.
  • Concernant l'encoding, Python suppose par defaut que le code est en utf-8. Sous les unix il n'est donc pas necessaire de le préciser.
  • De façon général je trouve les explications de cete partie pas forcément évidente et clair mais j'ai du mal a mettre le doigt sur ce qui me gène.

• Les variables:

  • liste des mots-clés réservés

    On sait déjà que async et await vont s'ajouter à la liste dans Python 3.5, peut être les rajouter en le précisant pour que le lecteur ne soit pas tenté de les utiliser.

  • Je suis un peu surpris de voir les "permutations" présenté si-tôt dans le cours. Pourquoi pas, ça permet de les faire réfléchir sur ce problème simple de permutation de variable. Pour autant n'oublie pas d'en reparler plus tard car cette forme simple de patern matching va plus loin en python :

  1 2 3 4 5 6 7 8

  >>> a = (1, 2, 3, 4, 5) >>> b, *c, d = a >>> b 1 >>> c [2, 3, 4] >>> d 5

  • float est une abréviation de « floting », signifiant flottant.

    Petite coquille sur "floating"

  • Le backslash indique à Python que le caractère qui le précède doit être échappé

    Précise peut être que du coup pour faire un backslash il faut le doubler. Ou utiliser les chaines raw.

  • J'ai peur que l'utilisation du backslash en fin de ligne ve vienne perturber le lecteur, c'est le meme symbole dans un autre contexte. Ton exemple sur les chaines est aussi limite car il utilise le fait que Python concatene des chaines consécutives, ce qui n'est pas évident de prime abord dans beaucoup de langages.

• Conditions et notion de boucles:

  • On appelle indentation le fait de décaler une ou plusieurs lignes de code d'une tabulation (à savoir 3 espaces)

    Dans le monde Python la convention largement respecté est d'en utiliser 4 et pas 3 ! La majorité des éditeurs et IDE suivent cette convention de la PEP-8. Je ne sais pas si toi tu en utilise 3 mais c'est vraiment pas terrible d'en conseiller 3.

  • Si vous vous baladez sur des forums, vous avez peut-être croisé ===.

    Il n'y a pas de triples egale en Python. Je comprend pas trop pourquoi tu parle de ça !

  • Le prédicat peut aussi être une variable de type bool. Ainsi if a: équivaut à if a == True:.

    Il y a là une conversion implicite. L'exemple syntaxiquement cannonique serait plutot l'équivalence à if bool(a) == True:

  • Le OU logique

    Ton exemple de code utilise un and et non un or.

  • Le trouve que tu va vite sur le PGCD. Tu devrais je pense plus détailler ton code, soit en dessous, soit avec les commentaires car un lecteur noob va pas facilement comprendre.

  • Le deuxième mot-clé que je voulais évoquer est continue. Quand Python rencontre cette instruction, il recommence à la première instruction de la boucle, sans exécuter la fin du passage en cours.

    Python ne saute pas à la premiere instruction mais au predicat. C'est important car ça veut dire qu'il y a le test de sortie de boucle qui est fait.

Voila pour le début, je continuerai dans l'aprem.

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures.

Bonjour Kje et merci pour ton retour.

Pour le ===, après quelques recherches je dois avouer une honteuse erreur où j’ai introduit un opérateur PHP.

Comme conseillé, je vais mettre la version 3.4, quitte à faire plus tard une maj du tuto pour 3.5.

Pour la partie présentation, je pense que j’ai voulu un peu trop simplifier et que je me suis retrouvé avec des raccourcis un peu rapides au final. Je me demande néanmoins si parler de CPython/JPython/… dès le premier chapitre n’est pas un peu prématuré. J’ai modifié la partie pour essayer de ne pas faire croire que Python est uniquement interprété, sans pour autant entrer trop dans les détails techniques.

Je vais essayer de voir si je peux améliorer le chapitre première approche.

Concernant l’indentation, il y a déjà une correction, mais entre la validation et la beta, il se peut qu’une maj ai été sautée. J’en utilise aussi 4, un petit problème d’accord avec Dr@zielux mais c’est réglé, comme sur des rails maintenant.

Pour le patern matching, c’est prévu avec les chapitres sur les listes et autres structures similaires.

Il y a là une conversion implicite. L'exemple syntaxiquement cannonique serait plutot l'équivalence à if bool(a) == True

a est déjà de type bool, il ne s’agit pas d’un int convertit. bool(a) me semble alors redondant, à moins que je n’ai pas compris ta remarque.

Je vais ajouter un peu plus d’explications sur le PGCD.

Merci pour toutes ces remarques. Je mets une maj partielle, notamment pour savoir si les modifications du premier chapitre partent dans le bon sens. Le reste suivra rapidement en théorie.

Oui j'en utilise aussi 4, mais comme je ne sais pas compter j'ai mis 3 (non en fait je ne savais plus combien faisait une tabulation, et j'avoue ne pas avoir cherché, honte à moi.)

Ah et martinqt, t'es fâché avec entrée tu me met entré à chaque fois

Techniquement je ne te conseil pas de parler de jython ou cython. Je faisait juste remarquer par ces exemples que ça n'a pas de sens de dire que Python est interprété. Ce n'est pas le langage qui l'est mais l'implémentation. Tout comme du code Python peut être compilé avec cython par exemple, du C peut être exécuté par un interpréteur dédié. Ça existe. Donc soit tu précise que cette remarque ne concerne que cpython, soit tu en parle pas du tout parce que ce n'est pas lié au langage.

Concernant la remarque sur le if a, j'avais pas compris que tu supposait que a était un bool. Ma remarque à l'avantage d'être canonique quelque soit le type de donnée. D'ailleurs si a est un bool, il n'y a pas de raccourcis à considéré. Le prédicat du if doit être un bool, ce n'est pas un raccourcis de lui fournir directement. Les opérateurs de comparaisons n'ont pas à être présent dans le prédicat. N'importe quel expression est accepté.

Enfin pour le triple égale, on a bien le is en python mais à prendre avec beaucoup de précautions. La majorité des amateurs qui ne comprennent pas toutes les subtilités du modèle objet de Python ne devrait l'utiliser que pour se comparer à None dont on a l'assurance qu'il est un singleton. Sur les types de bases il est généralement à éviter.

Bon courage pour la suite.

On sait déjà que async et await vont s'ajouter à la liste dans Python 3.5, peut être les rajouter en le précisant pour que le lecteur ne soit pas tenté de les utiliser.

Je crois que non justement, ils ont fait une exception (le lien est vers sametmax, page d’accueil NSFW) dans le parseur pour ne pas ajouter de mots clefs.

En fait il vont bidouiller le parseur pour que ce soit autorisé dans la 3.5 mais tu as des beaux warning dans la console. Ça deviendra une erreur de syntaxe dans la 3.7. Donc il vaut mieux éviter. Un debutant qui utiliserait ça se prendrai des warning à la con (source : les release note de la 3.5)

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures