Apprendre à programmer avec Python 3

Tout le monde se secoue !

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.

Merci a toi !

Dispo pour aider un peu.

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

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.

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

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

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.

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…

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

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.

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.

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.

Bonjour les agrumes !

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

Merci d'avance pour vos commentaires.

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 ?

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 ?

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.

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 :/