Apprendre à programmer avec Python 3

Adaptation du célèbre cours de Gérard Swinnen sur l'apprentissage de la programmation avec Python 3

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

Tout le monde se secoue ! :D

J'ai commencé (il y a 9 heures) la rédaction d'un tutoriel au doux nom de « Apprendre à programmer avec Python 3 » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Merci !


L'idée avait été évoquée ici et a fait son bout de chemin. Il s'agit donc de l'import du cours de Gérard Swinnen, réalisé sans trop de mal à l'aide de l'epub de developpez.com.

Des corrections automatiques ont déjà été appliquées pour corriger les titres, reformater les bouts de code et essayer d'uniformiser un peu le tout. Viennent maintenant les corrections manuelles, tout un travail de relecture est à mener (il reste beaucoup d'erreurs de formatage).

  • Correction des blocs de code (certains sont des lignes successives de code inline plutôt que des gros blocs de code) ;
  • Harmoniser les codes inline (il y a des balises de code et d'autres où c'est du gras qui est utilisé) ;
  • Déplacer ce qui doit l'être en introductions / conclusions ;
  • Et une relecture de chacun des chapitre pour les vérifier au cas par cas.

J'en appelle à toutes les personnes de bonne volonté, il y a 23 chapitres à traiter, je ne vous cache pas que ça va prendre un certain temps.

Édité par entwanne

Auteur du sujet

Pour l'intro du tuto, tout les liens sont faux, les references à développer probablement à revoir aussi

Eskimon

Oui, j'avais remarqué ça, mais c'est du cas par cas. Actuellement seules des modifications automatiques ont été apportées au contenu.


J'ai ajouté un tableau pour nous aider à nous organiser pour les relectures, sans se marcher sur les pieds.

Édité par entwanne

Quelques questions pour que tout le monde soit d’accord.

  • Pour les noms du genre « 3-A-1 Nom d’une sous-section », on retire la numérotation ?
  • Comment met-on en forme les exercices (liste numérotée, etc.) ?
  • Dans la majorité (tout) les tutoriels sur Python déjà écrits, on écrit « la fonction print » plutôt que « la fonction print() ». On garde la convention du livre ou on supprime les parenthèses (je suis pour la suppression) ?

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
  • Oui, j'ai déjà supprimé les numérotations des titres principaux mais ai oublié les sous-titres, ça pourrait être scripté d'ailleurs ;
  • Je n'ai pas d'idée pour les exercices, mais il faudrait une manière de bien les démarquer et les numéroter, de façon à pouvoir revenir dessus au chapitre 22 (ou déplacer les corrections dans chaque chapitre) ;
  • Oui, on harmonise avec le reste, c'est à dire :
    • « fonction print » ;
    • Suppression des parenthèses non nécessaires autour des conditions (j'en ai vu beaucoup) ;
    • Globalement tout ce qui peut être fait pour un meilleur respect de la PEP8.
Auteur du sujet

J'ajouterais aussi :

  • On conserve ce qui est en gras et/ou italique (à l'exception des codes inline, et encore, un code compris dans un texte italique reste en italique, ex. : la *fonction `print`*) ;
  • Pour les nombres qui n'appartiennent pas à des codes inline, on utilise des balises $ ;
  • On remplace les images représentant des formules mathématiques par la formule correspondante ;
  • On remplace les \ de fins de lignes par des double-espaces ;
  • On utilise || pour les codes de touches.

Édité par entwanne

On conserve ce qui est en gras et/ou italique (à l'exception des codes inline, et encore, un code compris dans un texte italique reste en italique, ex. : la *fonction `print`*) ;

Autant je vois tout à fait comment un code inline peut se retrouver en gras, autant je vois mal dans quelle situation un code inline en italique serait pertinent… Mais pourquoi pas.

Pour les nombres qui n'appartiennent pas à des codes inline, on utilise des balises $ ;

Tant qu’à faire, évitez… :)

Dans un texte comportant beaucoup de formules mathématiques, si vous utilisez des nombres en dehors desdites formules, mettez-les entre des balises $, afin qu’ils adoptent la police de MathJax, dans un but de cohérence à l’échelle du document. Au contraire, évitez autant que possible le MathJax, qui alourdit le chargement de la page, dans les autres situations.

Conventions typos pour ZdS

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0
Auteur du sujet

Autant je vois tout à fait comment un code inline peut se retrouver en gras, autant je vois mal dans quelle situation un code inline en italique serait pertinent… Mais pourquoi pas.

Dominus Carnufex

En fait je citais l'exemple de tête, mais il était effectivement en gras.

Tant qu’à faire, évitez… :)

Dominus Carnufex

En fait, l'auteur représente à plusieurs reprises des nombres décimaux avec une virgule, comment représenter ça au mieux et au plus simple ?

Le nombre 2,3 est inférieur à 4,56.

Ça passe très bien, je trouve : c’est comme ça qu’on fait dans la plupart des publications, sur Internet comme sous forme imprimée. Voyez par exemple, sur Wikipédia : pas de changement de police pour les nombres à irgule. :)

Après, si vraiment ça vous déplaît, vous pouvez envisager de mettre la plupart de ces nombres en code inline. En fait, un exemple d’un endroit qui poserait problème m’aiderait à mieux te conseiller.

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0
Auteur du sujet

Ok, va pour la police standard.

Je préfère réserver le code inline à ce qui représente vraiment du code. Pour un exemple, c'était en relisant cette section que je me suis posé ces questions.

Édité par entwanne

C’est typiquement un endroit où, dans un de mes contenus, j’aurais utilisé du code inline, parce qu’il s’agit d’une « citation » d’un bloc de code antérieur. Mais effectivement, la police habituelle est tout à fait correcte dans cette situation.

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0
Auteur du sujet

Bonjour les agrumes !

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

Merci d'avance pour vos commentaires.


Avis aux correcteurs : quand vous avez terminé de relire un chapitre, serait-il possible de passer son statut en « relu » dans le tableau ?

Édité par entwanne

Ok, je passe en « relu » ceux que j’ai fini de relire. Que fait-on pour les phrases d’avertissement ou d’information supplémentaire, on les laisse comme ça ou on les place dans les blocs ?

J’imagine qu’il y aura ensuite une relecture/réécriture technique pour supprimer les remarques à propos de Python 2 et celles obsolètes ?

Édité par Karnaj

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

Personnellement j'ai suivi ce qu'avait fait Wizix, en remplaçant les blocs « attention » et « important » par des blocs spéciaux (attention / information).

Je pense qu'on peut conserver les remarques sur Python 2, mais j'essaie de traiter dès la première passe ce qui me paraît incohérent (j'ai notamment corrigé des « C/C++ » dans les premiers chapitres).

Une fois qu'on aura fait le tour des chapitres, on pourra entamer une seconde lecture de façon à ce que chaque chapitre soit relu par au moins deux personnes différentes.

Petit problème pour les notes, celle-ci ne prennent pas les blocs de code. J'avais ceci :

1
2
3
4
5
6
7
8
[^note_73]: Ce système de notation est similaire à celui que nous utilisons pour désigner les variables d'un module, comme par exemple `math.pi` ou `string.ascii_lowercase`. Nous aurons l'occasion d'y revenir plus tard, mais sachez dès à présent que les modules peuvent en effet contenir des fonctions, mais aussi des classes et des variables. Essayez par exemple : 
```python
>>> import string
>>> string.capwords
>>> string.ascii_uppercase
>>> string.punctuation
>>> string.hexdigits
` ` `

Du coup le bloc de code est rendu avant la note, ce qui ne le fait pas du tout. Que dois-je faire ?

+0 -0

Je dirais de remplacer la note par un bloc information. Un problème du même genre se pose quand on a une note dans un bloc de code. Quand j’ai rencontré ce cas, j’ai mis la note en commentaire dans le code.

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

Je ne sais pas, le code a l'air d'être bien rendu dans les notes s'il arrive en première position, mais je n'arrive pas non plus à le faire précéder de texte (même avec des espaces en fin de ligne). J'ai testé aussi avec l'autre notation des blocs de code, sans effet :/

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

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