Apprendre à programmer avec Python 3

a marqué ce sujet comme résolu.

Enfin pour le triple égale, on a bien le is en python mais à prendre avec beaucoup de précautions.

C'est même complètement différent d'un éventuel === (dont la signification serait "les deux objets sont égaux en valeur ET de même type") puisque is teste l'identité (i.e. "ce sont deux références sur la même instance"). En fait, en dehors d'une comparaison explicite à None je ne vois aucun cas où un débutant pourrait vouloir utiliser cet opérateur.

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

D'abord, c'est censé être un projet communautaire, et à moins que j'aie la berlue beaucoup de gens se sont déclarées très motivées pour participer sur le thread associé… mais admettons que "communautaire" prenne ici son sens habituel de "y'a une communauté pour l'encourager mais une poignée de gens pour bosser dessus". Le fait est que mes dispos en ce moment sont très limitées, donc nécessairement que je suis moins actif sur ce tuto. Cela dit je trouve quand même très dommage de doublonner et diffuser l'effort parce que le projet de tuto sur GitHub n'est pas mort, et que je compte bien le faire repartir dès que j'en aurai l'occasion.

M'enfin soit.

PS : Tout le paragraphe "interprété ou compilé ?" est à virer selon moi. Ça fait des années que je me bats contre les idées reçues qu'il renferme, et qui sont fausses pour la plupart.

PPS :

Notre variable est alors un tiroir, avec un nom, son étiquette, et une valeur, son contenu.

C'est probablement, avec la métaphore de la boîte, la façon la plus éloignée de la réalité qui puisse exister pour introduire la notion de variable en Python. En Python, une variable est un nom, point.

+2 -0

Au passage dans les fonctions tu parle de paramètres obligatoires et de paramètres optionnels. Ce n'est pas du tout dans la logique de python. On parle plutôt de paramètres positionnels et par mot-clé. En realité un paramètre en python peut être :

  • Positionnel seulement (mais ce n'est pour le moment pas possible de créer des fonctions de ce type, mais certaines fonctions de la stlib ont des paramètres de ce genre)
  • Positionnel et par mot-clé (le cas général)
  • Par mot-clé uniquement:
1
2
def foo(a, b, c = 1, *, d=2, e=3):
    pass

Et encore je parle pas de *args et **kwargs.

EDIT: Au passage parler de global si tôt est une TRES TRES TRES MAUVAISE IDÉE !

ce mot clé est là pour des cas très particuliers mais on est pas en JS ou PHP. Il ne devrait être quasi jamais utilisé. C'est une mauvaise pratique ET source de beaucoup de bugs. Il vaut mieux ne pas en parler !

+1 -0

Ce sont les arguments qu'on passe à la fonction quand on l'appelle et non ses paramètres (formels, i.e. définis lors de sa déclaration) qui peuvent être positionnels ou non.

Pour les paramètres, ça ne me choque pas de parler de paramètres optionnels (pour lesquels on définit une valeur par défaut).

+0 -0

PS : Tout le paragraphe "interprété ou compilé ?" est à virer selon moi.

C'est une bonne idée, il est vrai que cela n'est probablement pas pertinent pour des débutants.

Notre variable est alors un tiroir

Même si la métaphore n’est pas très juste, je trouve qu’elle a l’avantage d’être potentiellement plus évocatrice pour une personne qui n’a pas fait de programmation. Je pense qu’il est plus facile d’appréhender leur rôle ainsi.

EDIT: Au passage parler de global si tôt est une TRES TRES TRES MAUVAISE IDÉE ! … Il vaut mieux ne pas en parler !

Je ne pense pas que tenter de dissimuler ce concept soit une bonne idée. Une mise en garde est présente à la fin du paragraphe. Ainsi, si plus tard le lecteur tombe sur un thread, et qu’une des solutions utilise un global, il aura une idée du principe et sera averti des risques, au lieu d’utiliser la solution sans la comprendre, en constatant que, pour l’instant, ça marche (ce qui, à mon avis, est le plus dangereux). Je laisse le paragraphe où il est, mais il pourra être déplacé vers la fin du cours plus tard.

que je suis

Mes propos faisait référence au tuto, pas à toi en particulier, et je suis navré que tu te sentes visé.

je compte bien le faire repartir

C’est tout ce que je souhaite pour ce tuto. Il me semble que rien n’empêche les deux tuto de coexister, c’est du moins ce qui avait été dit. J’ai rédigé un chapitre pour le sorcier (il reste certes à l’adapter au thème), et mon choix n’exclut en rien une future participation à ce tuto.

+0 -0

J'ai commencé à rapidement survoler ton tutoriel. Et il y a quelques chose qui me titille. Tu ne parles absolument pas de l'histoire de Python. Pur moi, dans tout cours apprenant un nouveau langage, un point historique est nécessaire. Même si ce n'est qu'un bref paragraphe, ce sera sûrement suffisant. Histoire de donner les dates clés et les principaux événements.

Ensuite, dans la lignée de ma première remarque, tu devrais peut-être ajouter quelques explications sur qu'est ce que Python. Ici, un débutant ne reçoit aucune informations, et commence à coder sans vraiment savoir ce qu'il utilise.

+0 -0

Merci pour ce retour. Je suis ploutot de l'avis de Kje. Je vais néanmoins glisser un lien vers la partie historique de wikipedia pour ceux que ca intéresse, comme ça on couvre tous les fronts.

Il est vrai qu'il manque une petite partie sur Python 2/3. Pour l'instant la seule est remarque est sur la partie téléchargement, mais je vais y remédier demain.

+0 -0

C'est important de parler de Python 2 pour pas que le débutant :

  • pense bien à préciser Python 3 quand il pose ses questions
  • il ne s'ettone pas que certaines solutions à ces problèmes ne fonctionnent pas.
  • qu'il verifie que les libs qu'il compte utiliser soient bien compatible.

Après j'utilise Python 3.4 quotidiennement au boulot et ça fait longtemps qu'on a pas eubde soucis de ce genre. La situation est clairement mieux qu'il y a quelques années. Mais il faut encore le préciser pour un débutant.

+0 -0

Notre variable est alors un tiroir

Même si la métaphore n’est pas très juste, je trouve qu’elle a l’avantage d’être potentiellement plus évocatrice pour une personne qui n’a pas fait de programmation. Je pense qu’il est plus facile d’appréhender leur rôle ainsi.

Il est surtout plus facile d'avoir dès le debut une image complètement différente du comportement réel des variables.

Peut-on mettre un même objet dans plusieurs tiroirs à la fois ? Non. Peut-on coller plusieurs étiquettes sur un objet ? Oui.

Un objet rangé dans un tiroir peut-il être modifié sans qu'on l'en sorte explicitement ? Non. Un objet sur lequel est collée une étiquette le peut-il ? Oui.

Un tiroir doit il s'adapter à la taille et la forme de son contenu ? Oui. Une étiquette ? Non.

Une variable en Python est TOUT sauf un tiroir. Je ne sais pas de quoi tu parles quand tu dis que ta métaphore est "plus évocatrice", mais il me semble très clair que :

  • soit tu ne sais pas comment sont foutus les variables et les espaces de noms en Python ;
  • soit tu n'as pas du tout pris le temps de chercher une métaphore adaptée pour expliquer ton propos.
+4 -0

Peut-on mettre un même objet dans plusieurs tiroirs à la fois ? Non. Peut-on coller plusieurs étiquettes sur un objet ? Oui.

Je comptais l’expliquer dans la partie sur les listes, afin d’illustrer le concept de pointeur. On peut le représenter comme plusieurs étiquettes collées sur un même tiroir. Je ne compte néanmoins pas parler de pointeur dès le troisième chapitre, sauf si tu penses qu’il faut évoquer cette notion dès le début.

Un objet rangé dans un tiroir peut-il être modifié sans qu'on l'en sorte explicitement ? Non. Un objet sur lequel est collée une étiquette le peut-il ? Oui.

Il va falloir développer un peu ce point, car je ne comprends pas à quoi tu fais référence.

Plutôt que de donner des réponses télégraphiques, tu aurais pu mettre un lien vers la référence originelle de cette métaphore (même si c’est en anglais) : http://foobarnbaz.com/2012/07/08/understanding-python-variables/

Néanmoins, je me rends compte que ma rédaction était maladroite. Je l’ai reformulé, notamment en enlevant le mot tiroir afin d’essayer de contenter tout le monde.

+0 -1

Je comptais l’expliquer dans la partie sur les listes, afin d’illustrer le concept de pointeur.

Il n'y a pas de pointeur en Python, il n'y a que des références. Si CPython implémente les références comme des pointeurs, c'est uniquement parce que les pointeurs sont la façon la plus légère et la plus naturelle possible pour implémenter des références en C.

Ce qu'il faut bien saisir, c'est qu'un débutant en Python n'a PAS à se poser la question du "valeur vs. référence" (qui pose problème aux débutants C et C++ notamment) : dans un langage où existe le passage par valeur, on pourrait effectivement parler de boîtes, mais pas ici. Le lecteur apprend Python, il s' attend à un discours le plus simple possible dans le référentiel de Python : introduire les variables comme des boîtes pour ensuite parler de pointeur, c'est enseigner C, pas Python.

Un objet rangé dans un tiroir peut-il être modifié sans qu'on l'en sorte explicitement ? Non. Un objet sur lequel est collée une étiquette le peut-il ? Oui.

Il va falloir développer un peu ce point, car je ne comprends pas à quoi tu fais référence.

1
2
3
4
>>> a = b = ['spam', 'eggs', 'bacon']
>>> a[2] = ['sausage']
>>> b
['spam', 'eggs', 'sausage']

"Je mets une liste dans les tiroirs a et b, je modifie celle du tiroir a, celle de b est modifiée alors que je n'y ai pas touché explicitement".

"Je colle deux étiquettes a et b sur un objet, je le modifie… il est modifié."

Plutôt que de donner des réponses télégraphiques, tu aurais pu mettre un lien vers la référence originelle de cette métaphore

Mes réponses sont courtes parce que je n'ai tout simplement pas plus que 5 minutes à passer sur le forum ces derniers temps. Néanmoins j'ignorais qu'un autre tutoriel avait fait usage de cette métaphore : je l'ai pondue (du moins une version différente qui voit les variables comme des "post-its") en rédigeant le mien et en cherchant l'image la moins faussée pour expliquer simplement ce mécanisme (c'est en fait une grosse table de hachage implicite) en Python. Cela dit je me félicite que d'autres aient compris le problème de cette façon et aient pris le temps de détailler cette métaphore avec des schémas.

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