supposons que vous ayez le code suivant

fruits = ("apples", "bananas", "loganberries")

def eat(food=fruits):
    ...

quand je vois la déclaration d'eat, la chose la moins étonnante est de penser que si le premier paramètre n'est pas donné, qu'il sera égal au tuple ("apples", "bananas", "loganberries")

cependant, supposé plus tard dans le code, je fais quelque chose comme

def some_random_function():
    global fruits
    fruits = ("blueberries", "mangos")

alors si les paramètres par défaut étaient liés à l'exécution de la fonction plutôt qu'à la déclaration de la fonction, alors je serais étonné (très mal) de découvrir que les fruits avaient changé. Ce serait plus étonnant IMO que de découvrir que votre foo fonction ci-dessus était la mutation de la liste.

le vrai problème réside dans les variables mutables, et toutes les langues ont ce problème dans une certaine mesure. Voici une question: supposons Qu'en Java j'ai le code suivant:

StringBuffer s = new StringBuffer("Hello World!");
Map<StringBuffer,Integer> counts = new HashMap<StringBuffer,Integer>();
counts.put(s, 5);
s.append("!!!!");
System.out.println( counts.get(s) );  // does this work?

maintenant, est-ce que ma carte utilise la valeur de la clé StringBuffer quand elle a été placée dans la carte, ou faut-il stocker la clé par référence? Quoi qu'il en soit, quelqu'un est étonné; soit la personne qui a essayé de sortir l'objet du Map en utilisant une valeur identique à celle avec laquelle ils l'ont mis, soit la personne qui ne semble pas pouvoir récupérer son objet même si la clé qu'ils utilisent est littéralement le même objet qui a été utilisé pour le mettre dans la carte (c'est en fait pourquoi Python ne permet pas à ses types de données intégrables mutables d'être utilisés comme des clés de dictionnaires).

Votre exemple est un bon d'un cas où les nouveaux venus en Python seront surpris et mordus. Mais je dirais que si nous "corrigions" cela, alors cela ne créerait qu'une situation différente où ils seraient mordus à la place, et que l'on serait encore moins intuitif. De plus, c'est toujours le cas lorsqu'il s'agit de variables mutables; vous rencontrez toujours des cas où quelqu'un pourrait s'attendre intuitivement à un comportement ou le contraire selon le code qu'il écrit.

I personnellement comme l'approche actuelle de Python: les arguments de fonction par défaut sont évalués lorsque la fonction est définie et que l'objet est toujours la fonction par défaut. Je suppose qu'ils pourraient utiliser une liste vide, mais ce genre de boîtier spécial causerait encore plus d'étonnement, sans parler d'être incompatible à l'envers.

AFAICS personne n'a encore posté la partie pertinente de la documentation :

les valeurs par défaut des paramètres sont évaluées lorsque la définition de la fonction est exécutée. cela signifie que l'expression est évaluée une fois, lorsque la fonction est définie, et que la même valeur" pré-calculée " est utilisée pour chaque appel. Ceci est particulièrement important pour comprendre quand un paramètre par défaut est un objet mutable, tel que une liste ou un dictionnaire: si la fonction modifie l'objet (par exemple, en ajoutant un élément à une liste), la valeur par défaut est en effet modifiée. Ce n'est généralement pas ce qui était prévu. Un moyen d'éviter cela est D'utiliser None comme valeur par défaut, et de tester explicitement cette valeur dans le corps de la fonction [...]

Je ne sais rien du fonctionnement interne de L'interpréteur Python (et je ne suis pas un expert en Compilateurs et interprètes non plus) donc ne me blâmez pas si je propose quelque chose d'insensible ou impossible.

pourvu que les objets python soient mutables je pense que cela devrait être pris en compte lors de la conception des arguments par défaut. Quand vous instanciez une liste:

a = []

vous vous attendez à obtenir un nouveau liste référencée par un .

Pourquoi l'a=[] dans

def x(a=[]):

instancier une nouvelle liste de définition de la fonction et non pas sur l'invocation? C'est tout comme vous demandez "si l'utilisateur ne fournit pas l'argument alors instantiate une nouvelle liste et l'utiliser comme si elle a été produite par l'appelant". Je pense que c'est plutôt ambigu:

def x(a=datetime.datetime.now()):

, voulez-vous un à défaut pour le type datetime correspondant lorsque vous êtes à la définition ou de l'exécution de x ? Dans ce cas, comme dans le précédent, je garderai le même comportement que si l'argument par défaut "assignment" était la première instruction de la fonction (datetime.now() est appelée sur l'invocation de la fonction). D'autre part, si l'utilisateur voulait la définition-time mapping il pourrait écrire:

b = datetime.datetime.now()
def x(a=b):

je sais, je sais: c'est une fermeture. Sinon, Python pourrait fournir un mot-clé pour forcer la définition - time binding:

def x(static a=b):

Eh bien, la raison est tout simplement que les reliures sont faites quand le code est exécuté, et la définition de la fonction est exécutée, Eh bien... lorsque les fonctions sont définies.

comparez ceci:

class BananaBunch:
    bananas = []

    def addBanana(self, banana):
        self.bananas.append(banana)

ce code souffre exactement du même événement inattendu. bananes est un attribut de classe, et donc, quand vous ajoutez des choses à elle, il est ajouté à toutes les instances de cette classe. La raison est exactement la même.

c'est juste "Comment cela fonctionne", et le faire fonctionner différemment dans le cas de la fonction serait probablement compliqué, et dans le cas de la classe probablement impossible, ou au moins ralentir l'instanciation de l'objet beaucoup, comme vous auriez à garder le code de classe autour et l'exécuter quand les objets sont créés.

Oui, c'est inattendu. Mais une fois que le penny tombe, il s'inscrit parfaitement dans la façon dont Python fonctionne en général. En fait, c'est un bon outil d'enseignement, et une fois que vous comprenez pourquoi cela se produit, vous grok python bien mieux.

qui dit qu'il devrait figurer bien en évidence dans tout bon tutoriel Python. Parce que comme vous le mentionnez, tout le monde se heurte à ce problème tôt ou tard.

je pense que la création d'objets lors de l'exécution serait la meilleure approche. Je suis moins sûr maintenant, puisque vous ne perdez pas certaines fonctionnalités utiles, bien qu'il puisse être la peine indépendamment tout simplement pour éviter la confusion des débutants. Les inconvénients sont:

1. Performance

def foo(arg=something_expensive_to_compute())):
    ...

si l'évaluation du temps d'appel est utilisée, alors la fonction coûteuse est appelée chaque fois que votre fonction est utilisée sans argument. Soit vous payez un prix élevé pour chaque appel, soit vous devez mettre en cache manuellement la valeur à l'extérieur, polluant votre espace de noms et ajoutant de la verbosité.

2. Forçant les paramètres liés

un truc utile est de lier les paramètres d'une lambda à la liaison courant d'une variable lorsque la lambda est créée. Par exemple:

funcs = [ lambda i=i: i for i in range(10)]

ceci retourne une liste de fonctions qui rendent 0,1,2,3... respectivement. Si le comportement est modifié, ils lieront plutôt i à la valeur call-time de i, de sorte que vous obtiendrez une liste de fonctions qui ont toutes retourné 9 .

la seule façon de mettre en oeuvre ceci autrement serait de créer une nouvelle fermeture avec le I bound, i.e.:

def make_func(i): return lambda: i
funcs = [make_func(i) for i in range(10)]

3. Introspection

considérer le code:

def foo(a='test', b=100, c=[]):
   print a,b,c

nous pouvons obtenir des informations sur les arguments et les valeurs par défaut en utilisant le module inspect , qui

>>> inspect.getargspec(foo)
(['a', 'b', 'c'], None, None, ('test', 100, []))

cette information est très utile pour la génération de documents, la métaprogrammation, les décorateurs, etc.

maintenant, supposons que le comportement des valeurs par défaut puisse être modifié de sorte qu'il soit l'équivalent de:

_undefined = object()  # sentinel value

def foo(a=_undefined, b=_undefined, c=_undefined)
    if a is _undefined: a='test'
    if b is _undefined: b=100
    if c is _undefined: c=[]

Cependant, nous avons perdu la capacité d'introspection, et voir ce que les arguments par défaut sont . Parce que les objets n'ont pas été construits, nous ne pouvons jamais les obtenir sans appeler la fonction. Le mieux que nous puissions faire est de stocker le code source et de le retourner sous forme de chaîne de caractères.

5 points en défense de Python

1. simplicité : le comportement est simple dans le sens suivant: La plupart des gens ne tombent dans ce piège qu'une seule fois, pas plusieurs fois.

2. Cohérence : Python toujours passe les objets, pas les noms. Le paramètre par défaut fait évidemment partie de la fonction position (et non le corps fonctionnel). Il par conséquent, devrait être évalué au moment de la charge du module (et seulement au moment de la charge du module, sauf s'il est imbriqué), en fonction du temps d'appel.

3. utilité : comme le souligne Frederik Lundh dans son explication de "valeurs des paramètres par défaut en Python" , le comportement actuel peut être très utile pour la programmation avancée. (À utiliser avec parcimonie.)

4. suffisant documentation : dans la documentation Python la plus basique, le tutoriel, le numéro est annoncé à haute voix comme un "attention" dans le première paragraphe de l'Article "Plus d'informations sur la Définition des" Fonctions . L'avertissement utilise même en gras, qui est rarement appliqué en dehors des rubriques. RTFM: lire le manuel fine.

5. Méta-apprentissage : Tomber dans le piège est en fait un très moment utile (au moins si vous êtes un apprenant réfléchi), parce que vous comprendrez mieux par la suite "La cohérence" ci-dessus et qui vous en apprendre beaucoup sur Python.

pourquoi ne pas vous introspecter?

je suis vraiment surpris personne n'a effectué l'perspicace introspection offert par Python ( 2 et 3 appliquer) sur callables.

donne une fonction simple func défini comme:

>>> def func(a = []):
...    a.append(5)

lorsque Python le rencontre, la première chose à faire est de le compiler afin de créer un objet code pour ce fonction. Alors que cette étape de compilation est faite, Python évalue * puis stocke les arguments par défaut (une liste vide [] ici) dans l'objet de fonction lui-même . Comme la première réponse l'a mentionné: la liste a peut maintenant être considérée comme un membre de la fonction func .

alors, faisons une introspection, un avant et un après pour examiner comment le liste est étendue à l'intérieur de l'objet de fonction. J'utilise Python 3.x pour ceci, pour Python 2 la même chose s'applique (utilisez __defaults__ ou func_defaults en Python 2; Oui, deux noms pour la même chose).

Fonction Avant Exécution:

>>> def func(a = []):
...     a.append(5)
...     

après que Python exécute cette définition, il va prendre tous les paramètres par défaut spécifiés ( a = [] ici) et cram eux dans l'attribut __defaults__ pour l'objet de fonction (section pertinente: Callables):

>>> func.__defaults__
([],)

o. k, donc une liste vide comme la seule entrée dans __defaults__ , comme prévu.

Fonction Après Exécution:

exécutons maintenant cette fonction:

>>> func()

maintenant, voyons ces __defaults__ encore une fois:

>>> func.__defaults__
([5],)

étonné? la valeur l'intérieur de l'objet change! Les appels consécutifs à la fonction s'ajouteront simplement à cet objet list intégré:

>>> func(); func(); func()
>>> func.__defaults__
([5, 5, 5, 5],)

Donc, voilà, la raison pour laquelle ce " flaw " arrive, c'est parce que les arguments par défaut font partie de l'objet de fonction. Il n'y a rien de bizarre ici, c'est juste un peu surprenant.

la solution courante pour combattre cela est d'utiliser None comme la valeur par défaut et puis initialiser dans le corps de fonction:

def func(a = None):
    # or: a = [] if a is None else a
    if a is None:
        a = []

puisque le corps de la fonction est exécuté de nouveau à chaque fois, vous obtenez toujours une nouvelle liste vide si aucun argument n'a été passé pour a .

pour vérifier que la liste dans __defaults__ est la même que celle utilisée dans la fonction func vous pouvez juste changer votre fonction pour retourner le id de la liste a utilisé à l'intérieur du corps de la fonction. Ensuite, comparez-le à la liste dans __defaults__ (position [0] dans __defaults__ ) et vous verrez comment ceux-ci se réfèrent effectivement à la même instance de liste:

>>> def func(a = []): 
...     a.append(5)
...     return id(a)
>>>
>>> id(func.__defaults__[0]) == func()
True

tous avec le pouvoir de l'introspection!

^* pour vérifier que Python évalue les arguments par défaut lors de la compilation de la fonction, essayez d'exécuter ce qui suit:

def bar(a=input('Did you just see me without calling the function?')): 
    pass  # use raw_input in Py2

comme vous remarquerez que input() est appelé avant que le processus de construction de la fonction et de la lier au nom bar soit fait.

ce comportement s'explique facilement par:

1. fonction (classe, etc.) déclaration est exécutée qu'une seule fois, la création de tous par défaut des objets de valeur
2. tout ce qui est passé par référence

:

def x(a=0, b=[], c=[], d=0):
    a = a + 1
    b = b + [1]
    c.append(1)
    print a, b, c

1. a ne change pas - toute cession d'appel crée un nouvel objet int - nouvel objet est imprimé
2. b ne change pas - le nouveau tableau est construit à partir de la valeur par défaut et imprimé
3. c changements-opération est effectuée sur le même objet - et il est imprimé

ce que vous demandez est pourquoi ceci:

def func(a=[], b = 2):
    pass

n'est pas en interne équivalent à ceci:

def func(a=None, b = None):
    a_default = lambda: []
    b_default = lambda: 2
    def actual_func(a=None, b=None):
        if a is None: a = a_default()
        if b is None: b = b_default()
    return actual_func
func = func()

sauf le cas de l'appel explicite func(None, None), que nous ignorerons.

en d'autres termes, au lieu d'évaluer les paramètres par défaut, pourquoi ne pas les stocker et les évaluer lorsque la fonction est appelée?

une réponse est probablement juste là-elle tournerait effectivement chaque fonction avec des paramètres par défaut dans une fermeture. Même si tout est caché dans l'interpréteur et pas une fermeture complète, les données doivent être stockées quelque part. Il serait plus lent et plus de mémoire.

1) le soi-disant problème de "L'Argument par défaut Mutable" est en général un exemple spécial démontrant que:

"Toutes les fonctions avec ce problème souffrent également d'un problème d'effet secondaire similaire sur le paramètre réel ,"

Cela va à l'encontre des règles de la programmation fonctionnelle, généralement non souhaitable et devrait être fixé ensemble.

exemple:

def foo(a=[]):                 # the same problematic function
    a.append(5)
    return a

>>> somevar = [1, 2]           # an example without a default parameter
>>> foo(somevar)
[1, 2, 5]
>>> somevar
[1, 2, 5]                      # usually expected [1, 2]

Solution : un copie

Une solution absolument sûre est de copy ou deepcopy l'objet d'entrée d'abord et ensuite de faire n'importe quoi avec la copie.

def foo(a=[]):
    a = a[:]     # a copy
    a.append(5)
    return a     # or everything safe by one line: "return a + [5]"

beaucoup de types mutables ont une méthode de copie comme some_dict.copy() ou some_set.copy() ou peuvent être copiés facilement comme somelist[:] ou list(some_list) . Chaque objet peut aussi être copié par copy.copy(any_object) ou plus complet par copy.deepcopy() (ce dernier utile si l'objet mutable est composé à partir d'objets mutables). Certains objets sont fondamentalement basés sur des effets secondaires comme l'objet "file" et ne peuvent pas être reproduits de manière significative par copie. copie

exemple de problème pour une question de SO similaire

class Test(object):            # the original problematic class
  def __init__(self, var1=[]):
    self._var1 = var1

somevar = [1, 2]               # an example without a default parameter
t1 = Test(somevar)
t2 = Test(somevar)
t1._var1.append([1])
print somevar                  # [1, 2, [1]] but usually expected [1, 2]
print t2._var1                 # [1, 2, [1]] but usually expected [1, 2]

Il ne devrait pas être ni enregistrés dans le attribut public d'une instance retournée par cette fonction. (À supposer que les attributs privé d'instance ne devraient pas être modifiés par convention par rapport à l'extérieur de cette classe ou de ces sous-classes. c'est à dire _var1 est un attribut privé )

Conclusion:

Les objets de paramètres d'entrée ne doivent pas être modifiés en place (mutés) ni être liés dans un objet retourné par la fonction. (Si nous visez plutôt programmation sans effets secondaires ce qui est fortement recommandé. voir Wiki à propos de" side effect " (les deux premiers paragraphes sont pertinents dans ce contexte.) .)

2)

Seulement si l'effet secondaire sur le paramètre réel est nécessaire mais non désiré sur le paramètre par défaut alors la solution utile est def ...(var1=None): if var1 is None: var1 = [] encore..

3) dans certains cas est la mutable comportement par défaut des paramètres utiles .

cela n'a en fait rien à voir avec les valeurs par défaut, sauf qu'il apparaît souvent comme un comportement inattendu lorsque vous écrivez des fonctions avec des valeurs par défaut modifiables.

>>> def foo(a):
    a.append(5)
    print a

>>> a  = [5]
>>> foo(a)
[5, 5]
>>> foo(a)
[5, 5, 5]
>>> foo(a)
[5, 5, 5, 5]
>>> foo(a)
[5, 5, 5, 5, 5]

Aucune valeur par défaut en vue dans ce code, mais vous obtenez exactement le même problème.

le problème est que foo est modifiant une variable mutable transmise par l'appelant, lorsque celui-ci ne s'y attend pas. Un Code comme ce serait très bien si la fonction était appelée quelque chose comme append_5 ; alors l'appelant appellerait la fonction afin de modifier la valeur qu'ils passent dans, et le comportement serait attendu. Mais une telle fonction serait très peu susceptible de prendre un argument par défaut, et ne retournerait probablement pas la liste (puisque l'appelant a déjà une référence à cette liste; celle qu'elle vient de transmettre).

votre original foo , avec un argument par défaut, ne devrait pas être modifier a s'il a été explicitement passé ou a obtenu la valeur par défaut. Votre code devrait laisser les arguments mutables seuls, à moins qu'il ne soit clair d'après le contexte/nom/documentation que les arguments sont censés être modifiés. Utiliser des valeurs mutables passées en arguments comme temporaireslocaux est une très mauvaise idée, que nous soyons en Python ou non et qu'il y ait des arguments par défaut impliqués ou non.

si vous avez besoin de manipuler de façon destructive un temporaire local dans le cours de calculer quelque chose, et vous avez besoin pour commencer votre manipulation à partir d'une valeur d'argument, vous devez faire une copie.

C'est une optimisation des performances. En raison de cette fonctionnalité, lequel de ces deux appels de fonction est le plus rapide selon vous?

def print_tuple(some_tuple=(1,2,3)):
    print some_tuple

print_tuple()        #1
print_tuple((1,2,3)) #2

je vais vous donner un indice. Voici le démontage (voir http://docs.python.org/library/dis.html ):

# 1

0 LOAD_GLOBAL              0 (print_tuple)
3 CALL_FUNCTION            0
6 POP_TOP
7 LOAD_CONST               0 (None)
10 RETURN_VALUE

# 2

 0 LOAD_GLOBAL              0 (print_tuple)
 3 LOAD_CONST               4 ((1, 2, 3))
 6 CALL_FUNCTION            1
 9 POP_TOP
10 LOAD_CONST               0 (None)
13 RETURN_VALUE

je doute du comportement expérimenté a une utilisation pratique (qui a vraiment utilisé des variables statiques en C, sans créer de bogues ?)

comme vous pouvez le voir, il est un avantage de performance lorsque vous utilisez des arguments par défaut immuables. Cela peut faire une différence si c'est une fonction fréquemment appelée ou si l'argument par défaut prend beaucoup de temps à construire. Aussi, gardez à l'esprit que Python n'est pas C. En C, vous avez des constantes qui sont assez libres. En Python, vous n'avez pas cet avantage.

sujet déjà occupé, mais d'après ce que j'ai lu ici, ce qui suit m'a aidé à réaliser comment il fonctionne à l'interne:

def bar(a=[]):
     print id(a)
     a = a + [1]
     print id(a)
     return a

>>> bar()
4484370232
4484524224
[1]
>>> bar()
4484370232
4484524152
[1]
>>> bar()
4484370232 # Never change, this is 'class property' of the function
4484523720 # Always a new object 
[1]
>>> id(bar.func_defaults[0])
4484370232

Python: L'Argument Par Défaut Mutable

les arguments par défaut sont évalués au moment où la fonction est compilée dans un objet de fonction. Lorsqu'il est utilisé par la fonction, plusieurs fois, par cette fonction, ils sont et restent le même objet.

Lorsqu'ils sont mutables, lorsqu'ils mutent (par exemple en y ajoutant un élément), ils restent mutés lors d'appels consécutifs.

ils restent mutés parce qu'ils sont les mêmes objet à chaque fois.

code équivalent:

puisque la liste est liée à la fonction lorsque l'objet de la fonction est compilé et instancié, ceci:

def foo(mutable_default_argument=[]): # make a list the default argument
    """function that uses a list"""

est presque exactement l'équivalent de ceci:

_a_list = [] # create a list in the globals

def foo(mutable_default_argument=_a_list): # make it the default argument
    """function that uses a list"""

del _a_list # remove globals name binding

Démonstration

Voici une démonstration, vous pouvez vérifier qu'ils sont le même objet à chaque fois qu'ils sont référencés par

• voyant que la liste est créée avant que la fonction ait fini de compiler vers un objet de fonction,
• observant que l'id est le même chaque fois que la liste est référencée,
• observant que la liste reste modifiée lorsque la fonction qui l'utilise est appelée une deuxième fois,
• observant l'ordre dans lequel la sortie est imprimée à partir de la source (que je numérotais commodément pour vous):

example.py

print('1. Global scope being evaluated')

def create_list():
    '''noisily create a list for usage as a kwarg'''
    l = []
    print('3. list being created and returned, id: ' + str(id(l)))
    return l

print('2. example_function about to be compiled to an object')

def example_function(default_kwarg1=create_list()):
    print('appending "a" in default default_kwarg1')
    default_kwarg1.append("a")
    print('list with id: ' + str(id(default_kwarg1)) + 
          ' - is now: ' + repr(default_kwarg1))

print('4. example_function compiled: ' + repr(example_function))


if __name__ == '__main__':
    print('5. calling example_function twice!:')
    example_function()
    example_function()

et l'exécuter avec python example.py :

1. Global scope being evaluated
2. example_function about to be compiled to an object
3. list being created and returned, id: 140502758808032
4. example_function compiled: <function example_function at 0x7fc9590905f0>
5. calling example_function twice!:
appending "a" in default default_kwarg1
list with id: 140502758808032 - is now: ['a']
appending "a" in default default_kwarg1
list with id: 140502758808032 - is now: ['a', 'a']

est-ce que cela viole le principe du "moindre étonnement"?

cet ordre d'exécution est souvent déroutant pour les nouveaux utilisateurs de Python. Si vous comprenez le modèle d'exécution Python, alors il devient très attendu.

l'instruction habituelle pour les nouveaux utilisateurs de Python:

mais ce c'est pourquoi l'instruction habituelle pour les nouveaux utilisateurs est de créer leurs arguments par défaut comme ceci à la place:

def example_function_2(default_kwarg=None):
    if default_kwarg is None:
        default_kwarg = []

cela utilise le None singleton comme un objet sentinelle pour dire à la fonction si oui ou non nous avons eu un argument autre que le défaut. Si nous n'avons pas d'argument, alors nous voulons utiliser une nouvelle liste vide, [] , comme valeur par défaut.

comme la section de tutoriel sur le flux de contrôle dit:

si vous ne voulez pas que la valeur par défaut soit partagée entre les appels suivants, vous pouvez écrire la fonction comme ceci à la place:

def f(a, L=None):
    if L is None:
        L = []
    L.append(a)
    return L

une solution de contournement simple utilisant aucun

>>> def bar(b, data=None):
...     data = data or []
...     data.append(b)
...     return data
... 
>>> bar(3)
[3]
>>> bar(3)
[3]
>>> bar(3)
[3]
>>> bar(3, [34])
[34, 3]
>>> bar(3, [34])
[34, 3]

ce comportement n'est pas surprenant si vous tenez compte de ce qui suit:

1. Le comportement de lire uniquement les attributs de classe lors de la tente d'assignation, et que
2. les fonctions sont des objets (bien expliquées dans la réponse acceptée).

le rôle de (2) a été largement couvert dans ce fil. (1) est probablement l'étonnement facteur causal, car ce comportement n'est pas" intuitif " lorsqu'il vient d'autres langues.

(1) est décrit dans le tutoriel Python sur les classes . Dans une tentative d'attribuer une valeur à un attribut de classe en lecture seule:

...toutes les variables trouvées en dehors de la portée la plus interne sont en lecture seule ( " une tentative d'écrire à une telle variable créera simplement un nouveau variable locale dans la portée la plus interne, laissant l'identité nom de la variable externe inchangé ).

retournez à l'exemple original et considérez les points ci-dessus:

def foo(a=[]):
    a.append(5)
    return a

ici foo est un objet et a est un attribut de foo (disponible à foo.func_defs[0] ). Comme a est une liste, a est mutable et est donc un attribut" read-write " de foo . Il est initialisé à la liste vide spécifiée par la signature lorsque la fonction est instanciée, et est disponible pour la lecture et l'écriture aussi longtemps que l'objet de la fonction existe.

appelant foo sans passer outre une valeur par défaut utilise la valeur par défaut de foo.func_defs . Dans ce cas, foo.func_defs[0] est utilisé pour a dans le champ d'application du code de l'objet de fonction. Changements à a changer foo.func_defs[0] , qui fait partie de l'objet foo et persiste entre l'exécution du code dans foo .

maintenant, comparez ceci à l'exemple de la documentation sur émulant le comportement d'argument par défaut d'autres langues , de sorte que la fonction signature par défaut sont utilisés à chaque fois que la fonction est exécutée:

def foo(a, L=None):
    if L is None:
        L = []
    L.append(a)
    return L

en prenant en compte (1) et (2) comportement souhaité: