surcharge de constructeur...

metalazz0

unread,

Sep 2, 2003, 5:14:51 PM9/2/03

to

Salut, je debute en python...
J'ai vu que l'on pouvait surcharger des operateurs.
Est ce qu'il possible de surcharger le constructeur d'une classe,
pour avoir plusieurs facon d'instancier un objet?

Merci.

Benoit Dejean

unread,

Sep 2, 2003, 5:52:05 PM9/2/03

to

quel intérêt puisque que le typage est dynamique et que Python fournit
des paramètres par défaut et nommés ? au pire, tu fais des méthodes de
classes qui jouent le rôle de fabrique

kaerbuhez

unread,

Sep 3, 2003, 4:12:31 PM9/3/03

to

Petite précision supplémentaire: en anglais on distingue "overloading"
et "overriding", je ne connais pas les traductions françaises, peut-être
"surcharge" et "redéfinition" ?

Exemple (en pseudo "strong typed python" code et avec toutes mes escuses
au BDFL ;-):

class Fille: # c'est la classe mère !
def reçoit(Invités invités): #=m1
prepareUnBonRepas()

class FilleCachée(Fille): # classe fille de Fille !!
def reçoit(Invités invités): #=m2 override m1
prepareDesSushis()
def reçoit(Pére mangezDesPommes): #=m3 overload m2
prepareDeLaTetePressee()

L'overloading est un concept de programmation fonctionelle et n'a rien à
voir avec l'héritage (en java il est d'ailleurs résolu statiquement) au
contraire de l'overloadong qui n'a de sens que dans un contexte OO.

Python ne permet effectivement pas l'overloading (et c'est vrai aussi
pour __init__ ) pour les raisons dites plus haut (paramètres par défaut)
et le rend inutile pour les mêmes raisons. Par contre, l'overriding est
pleinement supporté par exemple pour redéfinir (et non pas surcharger à
mon avis) les opérateurs.

bg

Bruno Desthuilliers

unread,

Sep 4, 2003, 6:53:03 AM9/4/03

to

kaerbuhez wrote:
> Benoit Dejean wrote:
>
>> Le Tue, 02 Sep 2003 21:14:51 +0000, metalazz0 a écrit :
>>
>>
>>> Salut, je debute en python...
>>> J'ai vu que l'on pouvait surcharger des operateurs. Est ce qu'il
>>> possible de surcharger le constructeur d'une classe, pour avoir
>>> plusieurs facon d'instancier un objet?
>>> Merci.
>>
>>
>>
>> quel intérêt puisque que le typage est dynamique et que Python fournit
>> des paramètres par défaut et nommés ? au pire, tu fais des méthodes de
>> classes qui jouent le rôle de fabrique
>
>
> Petite précision supplémentaire: en anglais on distingue "overloading"
> et "overriding", je ne connais pas les traductions françaises, peut-être
> "surcharge" et "redéfinition" ?

Exactement.

> Exemple (en pseudo "strong typed python" code et avec toutes mes escuses
> au BDFL ;-):
>
> class Fille: # c'est la classe mère !
> def reçoit(Invités invités): #=m1
> prepareUnBonRepas()
>
> class FilleCachée(Fille): # classe fille de Fille !!
> def reçoit(Invités invités): #=m2 override m1
> prepareDesSushis()
> def reçoit(Pére mangezDesPommes): #=m3 overload m2
> prepareDeLaTetePressee()
>
> L'overloading est un concept de programmation fonctionelle et n'a rien à
> voir avec l'héritage (en java il est d'ailleurs résolu statiquement) au
> contraire de l'overloadong qui n'a de sens que dans un contexte OO.

^^^^^^

C'est fait exprès, ou tu voulais dire 'overriding' ?-)

> Python ne permet effectivement pas l'overloading (et c'est vrai aussi
> pour __init__ ) pour les raisons dites plus haut (paramètres par défaut)
> et le rend inutile pour les mêmes raisons.

Pour préciser et compléter : l'impossibilité de surcharger des fonctions
en Python tient d'abord au typage dynamique (impossible de résoudre
l'appel de fonction en se basant sur le type des arguments), et
l'inutilité de la surcharge tient autant au typage dynamique qu'à la
possibilité de passer des arguments par défaut et des arguments non
précisés (*args, **kwargs).

Bruno

kaerbuhez

unread,

Sep 4, 2003, 5:44:26 PM9/4/03

to

C'est une erreur :-( Merci beaucoup d'avoir corrigé.

>
>> Python ne permet effectivement pas l'overloading (et c'est vrai aussi
>> pour __init__ ) pour les raisons dites plus haut (paramètres par
>> défaut) et le rend inutile pour les mêmes raisons.
>
>
> Pour préciser et compléter : l'impossibilité de surcharger des fonctions
> en Python tient d'abord au typage dynamique (impossible de résoudre
> l'appel de fonction en se basant sur le type des arguments), et
> l'inutilité de la surcharge tient autant au typage dynamique qu'à la
> possibilité de passer des arguments par défaut et des arguments non
> précisés (*args, **kwargs).
>

Je ne peux qu'opiner du bonnet (d'âne ;-).
>
> Bruno
>