Discussion :

[dividee]

en effet __init__ n'est pas le constructeur, mais l'initialisateur. Le constructeur etant bien __new__.

Je suis d'accord __init__ ne construit pas l'objet, mais en Java ou C++, par exemple, il me semble que this existe déjà quand on passe dans le constructeur. Ce qu'on appelle constructeur dans ces langages a la même fonction qu' __init__, et on pourrait donc faire la même remarque. Cela ne taraude sans doute pas les programmeurs de ces langages, car il n'y a pas d'équivalent au __new__ de Python, et il n'y a donc pas lieu de faire la différence entre constructeur et initialiseur, mais l'argument ne se limite pas à Python...

[wiztricks]

car il n'y a pas d'équivalent au __new__ de Python, et il n'y a donc pas lieu de faire la différence entre constructeur et initialiseur, mais l'argument ne se limite pas à Python...

C++ a un équivalent à __new__ qui permet d'allouer la mémoire un peu comme en Python... mais je ne sais plus s'il est utilisable pour retourner
une instance déjà créée pour faire un singleton sans 'getInstance' par exemple.

Mais je suis d'accord, le "constructeur" aka "ctor" initialise "au sens" mets des choses dans les attributs et il peut bien s'appeler __init__

- W

[yoshik]

doublon à supprimer SVP.
Merci.

[yoshik]

Salut les gars,

Merci de vos contributions.
J'ai été absent 3 jours, mais je n'ai pas lâché l'affaire :

Sauf si vous n'en avait pas besoin pour autre chose je ne vois pas l'utilité des méthodes pair et impair.

Non, je n'en ai pas besoin : j'ai précisé que mon exemple de code était bidon...
Mais oui j'en avais conscience et oui je l'ai fait exprès, par volonté d'être didactique (envers moi-même) :
je voulais voir si on pouvait dans une classe appeler une fonction à partir d'une autre.
Cette réponse obtenue, je voulais tester la possible utilisation de la récursivité à l'intérieur d'une fonction encapsulée dans une classe :
- si le 1er appel à la fonction vient d'une autre fonction à l'intérieur d'une classe,
- si le 1er appel à la fonction vient de l'intérieur d'une autre classe ou de l'extérieur.
En fait, en dehors de mon programme de conjugaison que j'ai en point de mire, ailleurs, quelqu'un a fourni une réponse informatique au problème suivant :

Face à nous, trois urnes transparentes.

Dans la première se trouvent 3n boules, les deux autres sont vides.
Je dois, en n étapes, arriver à avoir n boules dans chaque urne avec la règle de gestion suivante : à chaque étape p, je dois déplacer exactement p boules d'une urne vers une autre.
Comment fait on ?

La réponse était codée en VISUAL BASIC que j'ai traduit en Python en serrant au plus près le programme initial :

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# usr/bin/env python
# -*- coding: Latin-1 -*-
 
## Version 1 ##
 
def niveaup(nn,np,Urne,De,Vers):
    global sol
    for x in xrange(3):
        for y in xrange(3):
            if x!=y and Urne[x]>=np:
                De[np],Vers[np]=x,y
                Urne[x]-=np
                Urne[y]+=np
                if np==nn and Urne==[nn,nn,nn]:
                    sol+=1
                    print "   ---> Solution n°",sol,"<---"
                    Affiche_resultats(nn,De,Vers)
                if np<nn:
                    niveaup(nn,np+1,Urne,De,Vers)
                Urne[x]+=np
                Urne[y]-=np
    return
 
def Affiche_resultats(nn,De,Vers):
    U=[nn*3,0,0]
    for i in xrange(1,nn+1):
        U[De[i]]-=i
        U[Vers[i]]+=i       
        print "p =",i,"de ",'ABC'[De[i]],"vers ",'ABC'[Vers[i]],\
              "       * en A : %2i " % U[0],"* en B : %2i " % U[1],"* en C : %2i " % U[2],"*"
    print
 
# Programme principal
global sol
nmaxi,sol=5,0
De,Vers=[0]*(nmaxi+1),[0]*(nmaxi+1)
print "           ##########################"
print "           #    Début du calcul     #"
print "           ##########################"
print
nn=nmaxi
Urne=[nn*3,0,0]
niveaup(nn,1,Urne,De,Vers)
print 
print "           #   Fin du calcul  #"

Ainsi que vous le voyez, derrière le simple code "bidon" fourni au départ, se cachaient en fait, des objectifs bien précis et assez conséquents...
Et je ne suis ni fier, ni satisfait de ma traduction depuis le VB....
D'autant que je me suis trouvé contraint de faire appel à une variable globale pour gérer le compteur de nombre de solutions, celui-ci étant sinon remis à zéro à chaque récursion...
J'avais ajouté le paramètre supplémentaire sol en lignes 43 et 19 et passé en plus en ligne 6.
C'est alors que je me suis dit : une classe résoudrait probablement le problème en initialisant sol à 0 dans un __init__ en début de classe...
Alors pour y voir un peu plus clair, j'ai écrit le petit bout de code bidon que je vous ai soumis...
Maintenant vous avez l'origine de mes tourments.
Et ce nouveau code que je vous ai soumis est (pour moi) horrible : je suis sûr que
* on doit pouvoir être plus concis,
* on doit pouvoir éliminer les solutions doublons,
* on doit pouvoir utiliser une classe...

Maintenant que j'ai compris vos explications (pas celle de la controverse sur la
notion de constructeur, même si je les ai lues attentivement) précédentes, faut que je remette mon ouvrage sur le métier...
Mais je ne sais pas trop comment : quelqu'un peut-il me dire comment empêcher la variable sol de se remettre à 0 à chaque récursion, l'emploi de la variable globale, si elle contourne la difficulté, ne me fait pas avancer.

Des suggestions seraient les bienvenues...

Merci d'avance

@+