Discussion :

[scheme]

Bonjour à tous

Je suis en train d'apprendre le python grâce à l'excellent tuto de G.Swinnen. J'ai déjà un peu programmé en C, et je m'aperçois qu'en python les pointeurs n'ont pas l'air d'exister. J'aimerais savoir quels équivalents les développeurs ont conçus, et si on est obligé de passer par des variables globales. J'aimerais également avoir votre avis sur l'utilisation de ces variables globales, en cours de C notre formateur nous déconseillait toujours de les utiliser.Merci d'avance

[ju_bicycle]

J'vais p'tet dire une bétise, mais si tu programe en orienté objet, tu n'as pluss de probleme de variable globale...
Il me semble d'ailleur que c'est dit dans le tuto de Swinnen, quand il aborde la POO

[Antoine_935]

Les pointeurs existent bel et bien sous python. La seule différence est qu'ils sont implicites.

En python, tout est objet, même un nombre ou une chaîne de caractère. Il s'en suit que toutes les variables que tu manipules sont en fait des références.

On pourrait alors croire que le code suivant imprimerait "4", puisque la fonction change semble modifier la variable via son pointeur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
def change(var):
    var = 4
 
a = 5
change(a)
print(a)

Il se trouve que certains types sous python sont immuables. C'est le cas pour les nombres, les strings, les tuples, et sans doute d'autres.


Pour résumer, tout est objet dans python, toutes les variables sont donc des pointeurs, mais certains objets sont immuables.



Pour ce qui est des variables globales, elles sont à éviter à tout prix.
Les constantes sont acceptées par contre, puisque leur but est d'être global pour tenir une information commune.

Il y a certains cas en C qui requièrent réellement des variables globales (comme errno par exemple). En python on peut toujours s'en passer.

[scheme]

D'accord, merci de ta réponse très complète

C'est un petit peu dommage que les nombres et string soient immuables, mais quand je ferais de la poo j'aurais très vite oublié ce petit désagrément^^

Une petite chose me chagrine, du même rapport, concernant les strings.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ch="test"
ch[1]=a         #ne compile pas
ch=ch+"er"     #compile

c'est dû à la même chose d'après toi ?

[ju_bicycle]

héhéhé...alors la, tuto Swinnen P 125:
"Les chaines sont des séquences non modifiables"

Par conséquent

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ch[1]=a         #ne compile pas

Ne peut pas fonctionner

Par contre dans ta deuxieme ligne, tu ne modifie pas la chaine de charactere, mais tu ré-affecte la variable avec une nouvelle valeur et donc ca passe...

Maintenant si ta question est pourquoi c'est intrinsequement comme ca, j'avoue que je n'en sais rien...

[Zavonen]

@ Antoine_935
Tout ce que tu dis est parfaitement exact, mais le bout de code que tu utilises pour illustrer ton propos est assez malheureux, puisqu'il va à l'encontre de ce que tu affirmes.
Cet exemple est celui que l'on utilise toujours en C pour montrer l'utilité des pointeurs (une fonction standard ne peut modifier ses arguments à cause du passage par valeurs par défaut en C).
Cependant,même si les arguments sont passés en références, les fonctions Python évaluent leurs arguments avant d'évaluer le corps de la fonction.
Ainsi ton exemple, pour moi, ne marche pas...
Si je devais expliquer à quelqu'un qu'il est possible par un appel de fonction de modifier la valeur d'une variable, et pour illustrer ton propos sur les variables 'mutables' j'utiliserais plutôt:

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# -*- coding: utf-8 -*-
 
def changeglob(s):
    """changer une var. globale immuable"""
    globals()[s]=4
 
def changeliste(L):
    """changer un objet 'mutable'"""
    L[0]=1
 
a = 5
L=[2]
 
changeglob('a')
changeliste(L)
print a
print L

Toutefois toute personne venant de C te signifierait qu'en C également les tableaux sont passés par référence.

[Antoine_935]

C'est un petit peu dommage que les nombres et string soient immuables

Ne confonds pas, si les nombres sont immuables, ça ne t'empêche en aucun cas de réaffecter une valeur aux variables.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = 5
a += 6

Pour ce qui est des strings immuables, crois-moi, tu considèreras vite ça comme une bénédiction

@Zavonen: la conclusion de mon bout de code a disparu pdt la rédaction (j'ai été coupé...). Elle voulait bien sur illustrer que le changement à l'extérieur ne se faisait pas.

[scheme]

Oui on peut les réaffecter, mais la on ne passe pas par une fonction. Zovanen, en passant par global variable, on ne retourne pas justement a des variables globales ?

[josmiley]

tu peux utiliser un dictionnaire pour 'globaliser' des variables; l'inconveniant étant la syntax.

[Zavonen]

Zovanen, en passant par global variable, on ne retourne pas justement a des variables globales ?

Excuse mais je n'ai rien compris...

[scheme]

Excuse-moi, je crois que ce que j'ai dit n'a pas beaucoup de sens ni d'intérêt^^

[eyquem]

Je trouve qu’il y a pas mal de nébulosité dans cette file.

Il est possible que ce soit dû à la question initiale qui me semble comporter une confusion et une incompréhension.


1/

je m'aperçois qu'en python les pointeurs n'ont pas l'air d'exister
J'aimerais savoir (...) si on est obligé de passer par des variables globales.

C’est opposer là les pointeurs et les variables globales, c’est à dire admettre implicitement que ces deux notions ont un rapport.

Or je ne vois pas le rapport. À tel point que je me demande si scheme utilise bien dans cette phrase l’expression ’variables globales’ avec le sens précis qu’il a en Python, à savoir dans le cadre de la notion d’espace de noms.

Voilà pour la confusion.



2/

je m'aperçois qu'en python les pointeurs n'ont pas l'air d'exister. J'aimerais savoir quels équivalents les développeurs ont conçus

Comme le dit Antoine935, les pointeurs existent bel et bien en Python. Soit dit en passant, je me demande bien comment un programme pourrait tourner dans un ordinateur sans pointeurs.

Tous les langages utilisent des pointeurs, je crois donc (corrigez moi si je dis une bêtise) mais tous ne permettent pas aux programmeurs de les manipuler pour pouvoir intervenir directement dans la mémoire.

Ceux qui le permettent (pleinement en C et C++ ; sous une forme plus ou moins protégée en Pascal, Ada, FreeBASIC, Fortran, C#, D, Modula-2, Oberon) sont des langages proches de la machine (= dits de bas niveau). Dans des langages proche de l’humain (= dits de haut niveau), les pointeurs sont cachés: Java, Python...

Java est réputé par exemple pour ne pas utiliser les pointeurs, mais ne fait en fait que les dissimuler au développeurs aux travers de références. Cela se vérifie avant l'affichage d'une exception NullPointerException : les pointeurs sont très présents en Java, mais implicites - on ne peut pas les manipuler directement.

Soit dit en passant, je ne trouve pas qu’il soit exact de dire que les pointeurs sont implicites en Python et Java: ils ne sont pas implicites , ils sont cachés, c’est leur participation cachée qui est implicite dans les opérations sur les “varibales“.
Pour moi, pointeur implicite signifie qu’utiliser une référence revient à utiliser de façon cachée un pointeur,
tandis que participation implicite ne le signifie pas.

Car en réalité, leurs comportements sont différents, parce qu’un pointeur peut exister avec une valeur Null en ne pointant vers rien du tout ou avec une valeur qui va désigner une case mémoire,
tandis qu’une référence est une étiquette qui ne peut pas exister s’il n’y a pas d’objet existant préalablement auquel lui être attachée.

C’est toute la différence entre une variable qui est une boite d’emplacement fixe contenant un objet variable qui est DÉSIGNÉE par un pointeur (en C), et une variable qui est une étiquette en Python et qui DÉSIGNE un objet d’emplacement changeant selon sa valeur.

Pour bien visualiser ça:
http://www.biologeek.com/bonnes-prat...stuces-python/
au milieu de la page, chercher: Python a des "noms"

Cette différence de comportement relève en quelque sorte d’une couche du langage qui se surajoute aux possibilités d’un langage proche de la machine et fait du langage obtenu un langage plus proche de l’humain.

Chacune des deux options (langage proche de la machine, ou langage évolué ) présente ses avantages et ses inconvénients. La mise en comparaison des langages sous cet angle place dans un dilemme:
Un langage évolué perd la performance permise par la manipulation directe de la mémoire, mais procure une plus grande aisance de développement, et inversement.

L'utilisation des pointeurs permet d'avoir accès à la couche basse de l'ordinateur, un accès direct à la mémoire. On peut littéralement se déplacer de case mémoire en case mémoire. Cette technique permet d'effectuer des optimisations sur l'utilisation de la mémoire ou la performance en termes de vitesse.
(...)
L'utilisation des pointeurs est très puissante dans certains langages. Cette puissance et surtout le fait que l'on touche directement à la mémoire sans aucun contrôle, complexifie le développement d'une application.
(...)
Dans les langages de plus haut niveau, l'utilisation des pointeurs est supprimée, au profit des références et des tableaux dynamiques gérés par le compilateur. Les références remplissent certaines fonctions des pointeurs en supprimant l'accès à la mémoire. Cela évite beaucoup de problèmes, en contrepartie certaines utilisations et optimisations ne sont plus possibles.

http://fr.wikipedia.org/wiki/Pointeur_(programmation)

Je dirais donc que chercher s’il existe en Python des équivalents de la manipulation des pointeurs, c’est n’avoir pas tout à fait bien compris que choisir d’utiliser Python, c’est se décider à opter pour l’une des deux branches de l’alternative: soit les performance avec les difficultés de développement, soit l’efficacité en développement et maintenance avec des performances moindres.

Les différences concernant les pointeurs ne sont pas les seules à différencier langage de niveau machine et langage évolué, évidemment. Mais je crois que l’idée générale ci-dessus se retrouve grosso modo pour toutes les autres.

J’avoue qu’au début de mon utilisation de Python, j’avais encore moins compris que quiconque cette idée puisque je n’avais aucune conscience de la nature des différences entre langages, hormis la sommaire idée que “Python, c’est plus facile“...... Ouais....bof.... C’est plus humain, oui..... Mais si l’humain était facile à comprendre, ça se saurait.....

D'autres peuvent arguer qu'un langage moderne n'a aucun intérêt à compliquer la tâche d'un développeur, et devrait cacher ce genre de détails qui le divertissent de sa tâche principale : construire une application qui marche. C'est mal connaître les capacités et avantages des pointeurs.

--------------------------------------------------

Pour le reste de la file, je reprends ceci

Excuse mais je n'ai rien compris...

pour tous les posts.

La remarque de scheme (#8) n’est en effet pas du tout dénué de sens et d’intérêt puisqu’elle met le doigt sur une certaine confusion qui règne dans les diverses considérations de cette file du fait d’un méli-mélo de notions qui sont certes liées mais bien distinctes:
passage des arguments aux fonctions par valeur versus par référence,
immutabilité de certaines données,
variables globales versus locales.
Et par dessus le marché imprécision sur le mot “variable“: désigne-t-il un nom, un pointeur ou un objet ?



Cette confusion semble ne pas être spécifique à cette file, ou à maintes autres que j’ai déjà lues sur ces notions sans réagir sur ce forum, mais générique au sujet.

En recherchant sur le net, je suis en effet tombé sur des quantités de pages. En en lisant quelques unes, j’ai l’impression de comprendre. Mais en en lisant beaucoup, je finis par ne plus rien comprendre: ce que disent certains dans certaines pages se révèle contradictoire ou carrément contraire à ce que disent d’autres ailleurs, et au bout du compte je ne sais plus à quoi m’en tenir.


Il m’apparaît que le salmigondis qui règne dans ces notions est dû à une seule raison: le manque de rigueur sémantique dans l’emploi des termes.

Ce manque de rigueur se manifeste par:
- particularisme individuel:
un terme donné recouvre une acception variable d’une personne à une autre
- imprécision:
pour une même personne, un terme donné va être employé avec des sens en réalité différents selon le contexte
- particularisme de langage de programmation:
un même terme n’a pas exactement un sens constant d’un langage à un autre. Ceci est particulièrement criant et connu pour le terme de “variable“. Mais j’en suis arrivé à me demander si ce n’est pas aussi le cas du terme “référence“. Ce point est important dans la mesure où beaucoup de démonstrations s’assoient sur l’utilisation de fonctions pour lesquels il y a évidemment des passages d’arguments. Or ceux-ci peuvent se faire par passage de référence ou par passage de valeur. Mais j’ai l’impression que le mot référence n’a pas le même sens en C qu’en Python. Je n’en suis pas du tout sûr, il faudrait que je creuse la question, j’ai déjà dit que je n’y comprends en réalité plus rien.

Il me semble que cette situation se produit chaque fois que les mots, qui devraient donner accès aux notions concrètes, se muent en un voile plus ou moins opaque brouillant la compréhension de ces notions concrètes à cause qu’ils sont mal employés. Dans ce cas, la solution est de traverser le rideau pour considérer les processus concrets sans s’arrêter au piège des mots.

Mais le bazar me semble tel dans le sujet de la représentation et du comportement des variables en informatique que je ne me sens pas capable d’un tel travail de débroussaillage et de compréhension en peu de temps.
J’arrête donc là ces quelques considérations qui posent le problème et que je ne pouvais plus retenir.

Mais pour dire à quel point ces questions me posent un gros problème, j'ajoute:

je suis tellement choqué qu’il soit écrit

An object’s mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable.

c’est à dire précisément que les nombres sont immutables,
que j’en viens à penser qu’il y a peut être bien dans cet extrait une erreur, alors qu’il provient de cette doc officielle !!:
http://docs.python.org/reference/datamodel.html


Pour moi en effet, dans la mesure où l’objet qui représente un nombre n’est ni une structure de données comme une liste ou un dictionnaire, ni une donnée composite comme un string ou un tuple, mais un machin d’un bloc, il n’y a aucun sens à se demander si un objet “nombre’ est mutable ou non. Il me semble que si on se pose la question en Python, c’est qu’on fait encore la confusion entre ce qu’est un nombre étant la valeur d’une variable en C (variable dont le contenu=l’état=la valeur peut changer), et un nombre étant un objet qui ne subit aucune modification (ni d’état ni d’emplacement) en Python.

Si a=7, puis a=9, l’objet 7 ne va pas cesser d’exister tant que le collector garbage ne lui sera pas passé dessus, et a est une étiquette qui passe de l’objet 7 à l’objet 9; mais en aucun cas l’objet 7 n’est devenu l’objet 9 et il n'est envisageable qu'un nombre soit mutable.

J’estime que la notion de mutabilité ne concerne que des données présentant des “portions“: si une portion peut changer, la donnée est mutable, sinon elle ne l’est pas.
Premier cas: c’est une liste, dont chaque élément peut changer sans remettre en cause l’existence globale de l’objet liste global et son emplacement en mémoire.
Deuxième cas: c’est un tuple, dont aucun composant ne peut changer.
Dans un cas, c’est un élément qui peut changer, dans l’autre c’est un composant qui une fois figé dans la structure immutable ne peut plus changer.

Suis-je dans l'erreur ?
À l’appui de cette vision des choses, je constate dans la page suivante
http://zero202.free.fr/cs8-pyyh/html/ar01s02.html
qui me semble empreinte d’une certaine rigueur,
et qui parle des types nombre, chaîne, liste, tuple, dictionnaire et fichier,
qu'il n’est pas du tout question de mutabilité/immutabilité avant que d’aborder le type chaîne,
et que pour le type nombre: pas un mot là dessus.
Parce que ça n’a aucun sens.

Allez, je vais prendre une aspirine.

[Zavonen]

Il fallait que quelqu'un le fasse ...
Eyquem l'a fait.
Bravo et merci pour ta contribution.
Tu as bien mérité ton aspirine.

[josmiley]

en résumé ? ^^

[Zavonen]

en résumé ? ^^

Eyquem ne sait pas faire court, mais il a raison.
Je ne peux que vous conseiller de vous délecter de sa prose.
Vous y apprendrez toujours quelque chose.
C'est pas encore des alexandrins mais ça rime.

[Antoine_935]

Je ne peux que vous conseiller de vous délecter de sa prose.

Trop d'infos tue l'info.

C'est une pensée personnelle bien sur, mais il est souvent mieux de donner une information précise, sans noyer le lecteur.
Quitte à lui proposer des lectures supplémentaires.

[scheme]

Merci eyquem de ta participation fort constructive. Je dois avouer que j'étais un peu perdu. J'essaie souvent de faire des parallèles entre le C et le python, notamment au niveau de la mémoire. Et effectivement, quelques fois cela m'apporte de la confusion supplémentaire^^

Maintenant je sais que python utilise bien des pointeurs, mais qu'on n'a pas à les gérer directement (arrétez-moi si je me trompe), ce qui simplifie l'utilisation de langage mais diminue les performances et l'optimisation de la mémoire (et peut-être d'autres choses, je ne sais pas).

[Antoine_935]

mais diminue les performances et l'optimisation de la mémoire

Ces pertes ne sont absolument pas dues à la gestion implicite des pointeurs.
Elles sont dues au fonctionnement interne de python, dont le fait que ce soit un langage interprété.

[Fructidor]

Pas d'accord avec ceci:

Pour moi en effet, dans la mesure où l’objet qui représente un nombre n’est ni une structure de données comme une liste ou un dictionnaire, ni une donnée composite comme un string ou un tuple, mais un machin d’un bloc, il n’y a aucun sens à se demander si un objet “nombre’ est mutable ou non. Il me semble que si on se pose la question en Python, c’est qu’on fait encore la confusion entre ce qu’est un nombre étant la valeur d’une variable en C (variable dont le contenu=l’état=la valeur peut changer), et un nombre étant un objet qui ne subit aucune modification (ni d’état ni d’emplacement) en Python.

Le code suivant donne une classe implémentant un int mutable:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
class mymutableint(object):
    def __init__(self,value):
        self.value=value
    def __add__(self,b):
        return mymutableint(self.value+b.value)
    def __iadd__(self,c):
        if not isinstance(c,mymutableint):
            c=mymutableint(c)
        self.value+=c.value
        return a
    def __eq__(self,o):
        if not isinstance(o,mymutableint):
            return False
        return self.value==o.value
    def __hash__(self):
        return self.value
    def __str__(self):
        return str(self.value)
    def __repr__(self):
        return str(self)
 
 
a=mymutableint(1)
b=mymutableint(2)
print a+b
a+=3
print a

On a bien un truc "d'un bloc", mais qui est "mutable". Donc les deux notions ne vont pas forcément ensemble. Un object non mutable a un état (=la valeur de ses attributs) défini à la construction et non modifiable. De même, un tuple est non mutable.

Pourquoi faire des objets non mutables? Pour éviter les effets de bords. Notamment dans l'utilisation en tant que clé pour une map. A la suite de l'exemple précédant, considérer le code ci dessous:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
 
a=mymutableint(1)
c={a:'x'}
print c[mymutableint(1)]
a+=1
print c[mymutableint(1)] # ca rate!
print c[mymutableint(2)] # ca rate!
print c # et pourtant il y est!

En fait, on ne peut plus accéder a l'élément de la map!! Voila a quoi ca peut servir, les immutables.