Jeder, der lange genug an Python bastelt, wurde von folgendem Problem gebissen (oder in Stücke gerissen):

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

Python-Neulinge würden erwarten, dass diese Funktion immer eine Liste mit nur einem Element zurückgibt : [5]. Das Ergebnis ist stattdessen sehr unterschiedlich und sehr erstaunlich (für einen Anfänger):

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

Ein Manager von mir hatte einmal seine erste Begegnung mit dieser Funktion und nannte sie "einen dramatischen Designfehler" der Sprache. Ich antwortete, dass das Verhalten eine zugrunde liegende Erklärung habe, und es ist in der Tat sehr rätselhaft und unerwartet, wenn Sie die Interna nicht verstehen. Ich konnte jedoch die folgende Frage (für mich selbst) nicht beantworten: Was ist der Grund für die Bindung des Standardarguments bei der Funktionsdefinition und nicht bei der Funktionsausführung? Ich bezweifle, dass das erlebte Verhalten einen praktischen Nutzen hat (wer hat wirklich statische Variablen in C verwendet, ohne Fehler zu züchten?)

Bearbeiten :

Baczek machte ein interessantes Beispiel. Zusammen mit den meisten Ihrer Kommentare und insbesondere von Utaal habe ich weiter ausgeführt:

>>> def a():
...     print("a executed")
...     return []
... 
>>>            
>>> def b(x=a()):
...     x.append(5)
...     print(x)
... 
a executed
>>> b()
[5]
>>> b()
[5, 5]

Mir scheint, dass die Entwurfsentscheidung relativ dazu war, wo der Umfang der Parameter platziert werden sollte: innerhalb der Funktion oder "zusammen" damit?

Das Binden innerhalb der Funktion würde bedeuten, dass xes effektiv an den angegebenen Standard gebunden ist, wenn die Funktion aufgerufen und nicht definiert wird, was einen tiefen Fehler darstellen würde: Die defLinie wäre "hybrid" in dem Sinne, dass ein Teil der Bindung (von Das Funktionsobjekt würde bei der Definition und der Teil (Zuweisung von Standardparametern) zum Zeitpunkt des Funktionsaufrufs erfolgen.

Das tatsächliche Verhalten ist konsistenter: Alles in dieser Zeile wird ausgewertet, wenn diese Zeile ausgeführt wird, dh bei der Funktionsdefinition.

Tatsächlich ist dies kein Konstruktionsfehler, und es liegt nicht an Interna oder Leistung.
Es kommt einfach von der Tatsache, dass Funktionen in Python erstklassige Objekte sind und nicht nur ein Stück Code.

Sobald Sie sich auf diese Weise Gedanken machen, ist dies völlig sinnvoll: Eine Funktion ist ein Objekt, das anhand seiner Definition bewertet wird. Standardparameter sind eine Art "Mitgliedsdaten" und daher kann sich ihr Status von einem Aufruf zum anderen ändern - genau wie bei jedem anderen Objekt.

In jedem Fall hat Effbot eine sehr schöne Erklärung der Gründe für dieses Verhalten in Standardparameterwerte in Python .
Ich fand es sehr klar und empfehle wirklich, es zu lesen, um besser zu wissen, wie Funktionsobjekte funktionieren.

Angenommen, Sie haben den folgenden Code

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

def eat(food=fruits):
    ...

Wenn ich die Deklaration von eat sehe, ist es am wenigsten erstaunlich zu denken, dass wenn der erste Parameter nicht angegeben wird, er dem Tupel entspricht ("apples", "bananas", "loganberries")

Allerdings mache ich später im Code so etwas wie

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

Wenn dann Standardparameter bei der Funktionsausführung und nicht bei der Funktionsdeklaration gebunden wären, wäre ich (auf sehr schlechte Weise) erstaunt zu entdecken, dass Früchte geändert wurden. Dies wäre erstaunlicher, als zu entdecken, dass Ihre fooobige Funktion die Liste mutiert hat.

Das eigentliche Problem liegt in veränderlichen Variablen, und alle Sprachen haben dieses Problem bis zu einem gewissen Grad. Hier ist eine Frage: Angenommen, ich habe in Java den folgenden Code:

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?

Verwendet meine Karte nun den Wert des StringBufferSchlüssels, als er in die Karte eingefügt wurde, oder speichert sie den Schlüssel als Referenz? In jedem Fall ist jemand erstaunt; Entweder die Person, die versucht hat, das Objekt aus der MapVerwendung eines Werts herauszuholen, der mit dem Wert identisch ist, mit dem sie es eingegeben hat, oder die Person, die ihr Objekt scheinbar nicht abrufen kann, obwohl der von ihnen verwendete Schlüssel buchstäblich dasselbe Objekt ist Das wurde verwendet, um es in die Map einzufügen (aus diesem Grund erlaubt Python nicht, dass seine veränderlichen integrierten Datentypen als Wörterbuchschlüssel verwendet werden).

Ihr Beispiel ist ein gutes Beispiel für einen Fall, in dem Python-Neulinge überrascht und gebissen werden. Aber ich würde argumentieren, dass wenn wir dies "reparieren" würden, dies nur eine andere Situation schaffen würde, in der sie stattdessen gebissen würden, und dass eine noch weniger intuitiv wäre. Darüber hinaus ist dies beim Umgang mit veränderlichen Variablen immer der Fall; Sie stoßen immer auf Fälle, in denen jemand intuitiv das eine oder andere Verhalten erwarten kann, je nachdem, welchen Code er schreibt.

Ich persönlich mag Pythons aktuellen Ansatz: Standardfunktionsargumente werden ausgewertet, wenn die Funktion definiert ist und dieses Objekt immer der Standard ist. Ich nehme an, sie könnten im Sonderfall eine leere Liste verwenden, aber diese Art von Spezialgehäuse würde noch mehr Erstaunen hervorrufen, ganz zu schweigen davon, dass sie rückwärts inkompatibel sind.

Der relevante Teil der Dokumentation :

Standardparameterwerte werden bei der Ausführung der Funktionsdefinition von links nach rechts ausgewertet. Dies bedeutet, dass der Ausdruck einmal ausgewertet wird, wenn die Funktion definiert ist, und dass für jeden Aufruf derselbe „vorberechnete“ Wert verwendet wird. Dies ist besonders wichtig, um zu verstehen, wann ein Standardparameter ein veränderbares Objekt ist, z. B. eine Liste oder ein Wörterbuch: Wenn die Funktion das Objekt ändert (z. B. durch Anhängen eines Elements an eine Liste), wird der Standardwert tatsächlich geändert. Dies ist im Allgemeinen nicht beabsichtigt. Eine Möglichkeit, dies zu Noneumgehen, besteht darin, die Standardeinstellung zu verwenden und sie im Hauptteil der Funktion explizit zu testen, z.

def whats_on_the_telly(penguin=None):
    if penguin is None:
        penguin = []
    penguin.append("property of the zoo")
    return penguin

Ich weiß nichts über das Innenleben des Python-Interpreters (und ich bin auch kein Experte für Compiler und Interpreter), also beschuldigen Sie mich nicht, wenn ich etwas Unempfindliches oder Unmögliches vorschlage.

Vorausgesetzt, dass Python-Objekte veränderbar sind , sollte dies beim Entwerfen der Standardargumente berücksichtigt werden. Wenn Sie eine Liste instanziieren:

a = []

Sie erwarten eine neue Liste, auf die verwiesen wird a.

Warum sollte das a=[]in

def x(a=[]):

eine neue Liste zur Funktionsdefinition und nicht zum Aufruf instanziieren? Es ist so, als würden Sie fragen: "Wenn der Benutzer das Argument nicht bereitstellt, instanziieren Sie eine neue Liste und verwenden Sie sie so, als ob sie vom Anrufer erstellt wurde." Ich denke, das ist stattdessen mehrdeutig:

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

Benutzer, möchten Sie astandardmäßig die Datums- und Uhrzeitangabe festlegen, die der Definition oder Ausführung entspricht x? In diesem Fall werde ich wie im vorherigen das gleiche Verhalten beibehalten, als ob das Standardargument "Zuweisung" die erste Anweisung der Funktion wäre (beim Funktionsaufruf datetime.now()aufgerufen). Wenn der Benutzer andererseits die Definition-Zeit-Zuordnung wünschte, konnte er schreiben:

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

Ich weiß, ich weiß: das ist eine Schließung. Alternativ kann Python ein Schlüsselwort bereitstellen, um die Bindung der Definitionszeit zu erzwingen:

def x(static a=b):

Der Grund ist ganz einfach, dass Bindungen ausgeführt werden, wenn Code ausgeführt wird, und die Funktionsdefinition ausgeführt wird, na ja ... wenn die Funktionen definiert sind.

Vergleichen Sie dies:

class BananaBunch:
    bananas = []

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

Dieser Code leidet unter genau demselben unerwarteten Zufall. Bananen sind ein Klassenattribut. Wenn Sie also Dinge hinzufügen, werden sie allen Instanzen dieser Klasse hinzugefügt. Der Grund ist genau der gleiche.

Es ist nur "Wie es funktioniert", und es im Funktionsfall anders zu machen, wäre wahrscheinlich kompliziert und im Klassenfall wahrscheinlich unmöglich, oder zumindest die Objektinstanziierung stark zu verlangsamen, da Sie den Klassencode beibehalten müssten und führen Sie es aus, wenn Objekte erstellt werden.

Ja, das ist unerwartet. Aber sobald der Penny fällt, passt er perfekt zu Python im Allgemeinen. Tatsächlich ist es eine gute Lehrhilfe, und wenn Sie erst einmal verstanden haben, warum dies passiert, werden Sie Python viel besser verstehen.

Das heißt, es sollte in jedem guten Python-Tutorial eine herausragende Rolle spielen. Denn wie Sie bereits erwähnt haben, stößt jeder früher oder später auf dieses Problem.

Warum siehst du nicht nach innen?

Ich bin wirklich überrascht, dass niemand die aufschlussreiche Selbstbeobachtung durchgeführt hat, die Python ( 2und die 3Anwendung) für Callables bietet .

Gegeben eine einfache kleine Funktion funcdefiniert als:

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

Wenn Python darauf stößt, wird es zunächst kompiliert, um ein codeObjekt für diese Funktion zu erstellen . Während dieser Kompilierungsschritt wertet Python * aus und speichert die Standardargumente (hier eine leere Liste ) im Funktionsobjekt selbst[] . Wie in der Top-Antwort erwähnt: Die Liste akann nun als Mitglied der Funktion betrachtet werden func.

Lassen Sie uns also vorher und nachher eine Selbstbeobachtung durchführen, um zu untersuchen, wie die Liste innerhalb des Funktionsobjekts erweitert wird. Ich benutze Python 3.xdafür, für Python 2 gilt das Gleiche (benutze __defaults__oder func_defaultsin Python 2; ja, zwei Namen für das gleiche Ding).

Funktion vor der Ausführung:

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

Nachdem Python diese Definition ausgeführt hat, werden alle a = []hier angegebenen Standardparameter verwendet und im __defaults__Attribut für das Funktionsobjekt (relevanter Abschnitt: Callables) gespeichert:

>>> func.__defaults__
([],)

Ok, also eine leere Liste als einzelner Eintrag in __defaults__, genau wie erwartet.

Funktion nach Ausführung:

Lassen Sie uns nun diese Funktion ausführen:

>>> func()

Nun wollen wir diese noch __defaults__einmal sehen:

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

Erstaunt? Der Wert im Objekt ändert sich! Aufeinanderfolgende Aufrufe der Funktion werden jetzt einfach an das eingebettete listObjekt angehängt :

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

Der Grund, warum dieser 'Fehler' auftritt, liegt darin, dass Standardargumente Teil des Funktionsobjekts sind. Hier ist nichts Seltsames los, es ist alles nur ein bisschen überraschend.

Die übliche Lösung, um dem entgegenzuwirken, besteht darin, Noneals Standard zu verwenden und dann im Funktionskörper zu initialisieren:

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

Da der Funktionskörper jedes Mal neu ausgeführt wird, erhalten Sie immer eine neue leere Liste, wenn kein Argument übergeben wurde a.

Um weiter zu überprüfen, ob die Liste in __defaults__mit der in der Funktion verwendeten funcübereinstimmt, können Sie einfach Ihre Funktion ändern, um iddie Liste zurückzugeben, adie im Funktionskörper verwendet wird. Vergleichen Sie es dann mit der Liste in __defaults__(Position [0]in __defaults__) und Sie werden sehen, wie sich diese tatsächlich auf dieselbe Listeninstanz beziehen:

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

Alles mit der Kraft der Selbstbeobachtung!

^* Um zu überprüfen, ob Python die Standardargumente während der Kompilierung der Funktion auswertet, führen Sie Folgendes aus:

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

Wie Sie feststellen werden, input()wird es aufgerufen, bevor die Funktion erstellt und an den Namen gebunden barwird.

Früher dachte ich, dass das Erstellen der Objekte zur Laufzeit der bessere Ansatz wäre. Ich bin mir jetzt weniger sicher, da Sie einige nützliche Funktionen verlieren, obwohl es sich lohnen kann, nur um Verwirrung bei Neulingen zu vermeiden. Die Nachteile dabei sind:

1. Leistung

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

Wenn die Auswertung der Anrufzeit verwendet wird, wird die teure Funktion jedes Mal aufgerufen, wenn Ihre Funktion ohne Argument verwendet wird. Sie zahlen entweder einen teuren Preis für jeden Anruf oder müssen den Wert manuell extern zwischenspeichern, Ihren Namespace verschmutzen und Ausführlichkeit hinzufügen.

2. Erzwingen gebundener Parameter

Ein nützlicher Trick besteht darin, Parameter eines Lambdas an die aktuelle Bindung einer Variablen zu binden , wenn das Lambda erstellt wird. Zum Beispiel:

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

Dies gibt eine Liste von Funktionen zurück, die jeweils 0,1,2,3 ... zurückgeben. Wenn das Verhalten geändert wird, werden sie stattdessen ian den Aufrufzeitwert von i gebunden, sodass Sie eine Liste der Funktionen erhalten, die alle zurückgegeben wurden 9.

Die einzige Möglichkeit, dies anderweitig zu implementieren, besteht darin, einen weiteren Abschluss mit der i-Grenze zu erstellen, dh:

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

3. Selbstbeobachtung

Betrachten Sie den Code:

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

Informationen über die Argumente und Standardeinstellungen können wir mit dem inspectModul abrufen

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

Diese Informationen sind sehr nützlich für Dinge wie Dokumentenerstellung, Metaprogrammierung, Dekorateure usw.

Angenommen, das Verhalten der Standardeinstellungen könnte so geändert werden, dass dies dem Äquivalent von:

_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=[]

Allerdings haben wir die Möglichkeit , selbst zu überwachen, verloren und sehen , was die Standardargumente sind . Da die Objekte nicht erstellt wurden, können wir sie niemals erreichen, ohne die Funktion tatsächlich aufzurufen. Das Beste, was wir tun können, ist, den Quellcode zu speichern und als Zeichenfolge zurückzugeben.

5 Punkte zur Verteidigung von Python

1. Einfachheit : Das Verhalten ist im folgenden Sinne einfach: Die meisten Menschen geraten nur einmal in diese Falle, nicht mehrmals.

2. Konsistenz : Python übergibt immer Objekte, keine Namen. Der Standardparameter ist offensichtlich Teil der Funktionsüberschrift (nicht des Funktionskörpers). Es sollte daher zur Ladezeit des Moduls (und nur zur Ladezeit des Moduls, sofern nicht verschachtelt) und nicht zur Funktionsaufrufzeit ausgewertet werden.

3. Nützlichkeit : Wie Frederik Lundh in seiner Erklärung zu "Standardparameterwerte in Python" ausführt , kann das aktuelle Verhalten für die erweiterte Programmierung sehr nützlich sein. (Sparsam verwenden.)

4. Ausreichende Dokumentation : In der grundlegendsten Python-Dokumentation, dem Lernprogramm, wird das Problem im ersten Unterabschnitt des Abschnitts "Weitere Informationen zum Definieren von Funktionen" lautstark als "Wichtige Warnung" angekündigt . Die Warnung verwendet sogar Fettdruck, der nur selten außerhalb von Überschriften angewendet wird. RTFM: Lesen Sie das feine Handbuch.

5. Meta-Lernen : In die Falle zu tappen ist tatsächlich ein sehr hilfreicher Moment (zumindest wenn Sie ein reflektierender Lernender sind), da Sie anschließend den obigen Punkt "Konsistenz" besser verstehen und dadurch viel über Python lernen.

Dieses Verhalten lässt sich leicht erklären durch:

1. Die Funktionsdeklaration (Klasse usw.) wird nur einmal ausgeführt, wodurch alle Standardwertobjekte erstellt werden
2. Alles wird als Referenz übergeben

Damit:

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

1. a ändert sich nicht - jeder Zuweisungsaufruf erstellt ein neues int-Objekt - ein neues Objekt wird gedruckt
2. b ändert sich nicht - neues Array wird aus dem Standardwert erstellt und gedruckt
3. c Änderungen - Operation wird an demselben Objekt ausgeführt - und es wird gedruckt

Was Sie fragen, ist, warum dies:

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

ist intern nicht gleichbedeutend damit:

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()

mit Ausnahme des expliziten Aufrufs von func (None, None), den wir ignorieren werden.

Mit anderen Worten, anstatt Standardparameter auszuwerten, warum nicht jeden von ihnen speichern und sie auswerten, wenn die Funktion aufgerufen wird?

Eine Antwort ist wahrscheinlich genau dort - sie würde effektiv jede Funktion mit Standardparametern in einen Abschluss verwandeln. Selbst wenn alles im Interpreter versteckt ist und kein vollständiger Abschluss vorliegt, müssen die Daten irgendwo gespeichert werden. Es wäre langsamer und würde mehr Speicher verbrauchen.

1) Das sogenannte Problem des "veränderlichen Standardarguments" ist im Allgemeinen ein spezielles Beispiel, das zeigt, dass:
"Alle Funktionen mit diesem Problem leiden auch unter einem ähnlichen Nebenwirkungsproblem des tatsächlichen Parameters ."
das gegen die Regeln der funktionalen Programmierung verstößt. in der Regel nicht zu beachten und sollte beide zusammen befestigt werden.

Beispiel:

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]

Lösung : eine Kopie
Eine absolut sichere Lösung besteht darin, zuerst das Eingabeobjekt copyoder deepcopydas Eingabeobjekt zu erstellen und dann alles mit der Kopie zu tun.

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

Viele eingebaute veränderbare Typen haben eine Kopiermethode wie some_dict.copy()oder some_set.copy()oder können einfach wie somelist[:]oder kopiert werden list(some_list). Jedes Objekt kann auch von copy.copy(any_object)oder gründlicher von kopiert werden copy.deepcopy()(letzteres ist nützlich, wenn das veränderbare Objekt aus veränderlichen Objekten besteht). Einige Objekte basieren grundsätzlich auf Nebenwirkungen wie "Datei" -Objekt und können durch Kopieren nicht sinnvoll reproduziert werden. Kopieren

Beispielproblem für eine ähnliche SO-Frage

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]

Es sollte weder in einem öffentlichen Attribut einer von dieser Funktion zurückgegebenen Instanz gespeichert werden. (Angenommen, private Attribute der Instanz sollten nicht von außerhalb dieser Klasse oder Unterklassen gemäß Konvention geändert werden. Dies _var1ist ein privates Attribut.)

Schlussfolgerung:
Eingabeparameterobjekte sollten nicht an Ort und Stelle geändert (mutiert) oder an ein von der Funktion zurückgegebenes Objekt gebunden werden. (Wenn wir das Programmieren ohne Nebenwirkungen bevorzugen, was dringend empfohlen wird. Siehe Wiki über "Nebenwirkungen" (Die ersten beiden Absätze sind in diesem Zusammenhang relevant.)

2)
Nur wenn die Nebenwirkung auf den tatsächlichen Parameter erforderlich, aber auf den Standardparameter unerwünscht ist, ist die nützliche Lösung def ...(var1=None): if var1 is None: var1 = [] Mehr.

3) In einigen Fällen ist das veränderbare Verhalten von Standardparametern nützlich .

Dies hat eigentlich nichts mit Standardwerten zu tun, außer dass es häufig als unerwartetes Verhalten auftritt, wenn Sie Funktionen mit veränderlichen Standardwerten schreiben.

>>> 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]

In diesem Code sind keine Standardwerte in Sicht, aber Sie erhalten genau das gleiche Problem.

Das Problem ist , dass foosich Modifizierung eine veränderbare Variable in dem Aufrufer übergeben, wenn der Anrufer dies nicht erwarten. Code wie dieser wäre in Ordnung, wenn die Funktion so etwas wie aufgerufen würdeappend_5 ; dann würde der Aufrufer die Funktion aufrufen, um den übergebenen Wert zu ändern, und das Verhalten würde erwartet. Es ist jedoch sehr unwahrscheinlich, dass eine solche Funktion ein Standardargument annimmt und die Liste wahrscheinlich nicht zurückgibt (da der Aufrufer bereits einen Verweis auf diese Liste hat; die, die er gerade übergeben hat).

Ihr Original foomit einem Standardargument sollte nicht ändern, aob es explizit übergeben wurde oder den Standardwert erhalten hat. Ihr Code sollte veränderbare Argumente in Ruhe lassen, es sei denn, aus dem Kontext / Namen / der Dokumentation geht hervor, dass die Argumente geändert werden sollen. Die Verwendung von veränderlichen Werten, die als Argumente als lokale temporäre Werte übergeben werden, ist eine äußerst schlechte Idee, unabhängig davon, ob wir uns in Python befinden oder nicht und ob es sich um Standardargumente handelt oder nicht.

Wenn Sie ein lokales temporäres Element im Verlauf der Berechnung destruktiv manipulieren müssen und Ihre Manipulation von einem Argumentwert aus starten müssen, müssen Sie eine Kopie erstellen.

Bereits beschäftigtes Thema, aber nach dem, was ich hier gelesen habe, hat mir Folgendes geholfen zu erkennen, wie es intern funktioniert:

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

Es ist eine Leistungsoptimierung. Welcher dieser beiden Funktionsaufrufe ist Ihrer Meinung nach aufgrund dieser Funktionalität schneller?

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

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

Ich gebe dir einen Hinweis. Hier ist die Demontage (siehe 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

Ich bezweifle, dass das erlebte Verhalten einen praktischen Nutzen hat (wer hat wirklich statische Variablen in C verwendet, ohne Fehler zu züchten?)

Wie Sie sehen, bietet die Verwendung unveränderlicher Standardargumente einen Leistungsvorteil. Dies kann einen Unterschied machen, wenn es sich um eine häufig aufgerufene Funktion handelt oder die Erstellung des Standardarguments lange dauert. Denken Sie auch daran, dass Python nicht C ist. In C haben Sie Konstanten, die ziemlich frei sind. In Python haben Sie diesen Vorteil nicht.

Python: Das veränderbare Standardargument

Standardargumente werden zum Zeitpunkt der Kompilierung der Funktion zu einem Funktionsobjekt ausgewertet. Wenn sie von der Funktion mehrfach verwendet werden, sind und bleiben sie dasselbe Objekt.

Wenn sie veränderlich sind, wenn sie mutiert sind (z. B. durch Hinzufügen eines Elements), bleiben sie bei aufeinanderfolgenden Aufrufen mutiert.

Sie bleiben mutiert, weil sie jedes Mal dasselbe Objekt sind.

Äquivalenter Code:

Da die Liste beim Kompilieren und Instanziieren des Funktionsobjekts an die Funktion gebunden ist, gilt Folgendes:

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

ist fast genau gleichbedeutend damit:

_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

Demonstration

Hier ist eine Demonstration: Sie können jedes Mal, wenn auf sie verwiesen wird, überprüfen, ob es sich um dasselbe Objekt handelt

• zu sehen, dass die Liste erstellt wird, bevor die Funktion zu einem Funktionsobjekt kompiliert wurde,
• Beachten Sie, dass die ID jedes Mal, wenn auf die Liste verwiesen wird, dieselbe ist.
• Beachten Sie, dass die Liste geändert bleibt, wenn die Funktion, die sie verwendet, ein zweites Mal aufgerufen wird.
• Beobachten Sie die Reihenfolge, in der die Ausgabe von der Quelle gedruckt wird (die ich bequem für Sie nummeriert habe):

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()

und laufen lassen mit 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']

Verstößt dies gegen das Prinzip des "geringsten Erstaunens"?

Diese Ausführungsreihenfolge ist für neue Benutzer von Python häufig verwirrend. Wenn Sie das Python-Ausführungsmodell verstehen, wird es durchaus erwartet.

Die übliche Anweisung für neue Python-Benutzer:

Aus diesem Grund besteht die übliche Anweisung für neue Benutzer darin, stattdessen ihre Standardargumente wie folgt zu erstellen:

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

Dies verwendet den None-Singleton als Sentinel-Objekt, um der Funktion mitzuteilen, ob wir ein anderes Argument als das Standardargument erhalten haben oder nicht. Wenn wir kein Argument erhalten, möchten wir []standardmäßig eine neue leere Liste verwenden .

Im Tutorial-Abschnitt zum Kontrollfluss heißt es:

Wenn Sie nicht möchten, dass die Standardeinstellung für nachfolgende Aufrufe freigegeben wird, können Sie die Funktion stattdessen wie folgt schreiben:

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

Die kürzeste Antwort wäre wahrscheinlich "Definition ist Ausführung", daher macht das ganze Argument keinen strengen Sinn. Als ein besseres Beispiel können Sie Folgendes anführen:

def a(): return []

def b(x=a()):
    print x

Hoffentlich reicht es zu zeigen, dass defes nicht einfach oder nicht sinnvoll ist, die Standardargumentausdrücke zum Ausführungszeitpunkt der Anweisung nicht auszuführen , oder beides.

Ich bin damit einverstanden, dass es ein Problem ist, wenn Sie versuchen, Standardkonstruktoren zu verwenden.

Eine einfache Problemumgehung mit None

>>> 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]

Dieses Verhalten ist nicht überraschend, wenn Sie Folgendes berücksichtigen:

1. Das Verhalten von schreibgeschützten Klassenattributen bei Zuweisungsversuchen und das
2. Funktionen sind Objekte (in der akzeptierten Antwort gut erklärt).

Die Rolle von (2) wurde in diesem Thread ausführlich behandelt. (1) ist wahrscheinlich der Faktor, der das Erstaunen verursacht, da dieses Verhalten nicht "intuitiv" ist, wenn es aus anderen Sprachen kommt.

(1) wird im Python- Tutorial zu Klassen beschrieben . Bei dem Versuch, einem schreibgeschützten Klassenattribut einen Wert zuzuweisen:

... alle Variablen, die außerhalb des innersten Bereichs gefunden werden, sind schreibgeschützt ( ein Versuch, in eine solche Variable zu schreiben, erstellt einfach eine neue lokale Variable im innersten Bereich, wobei die identisch benannte äußere Variable unverändert bleibt ).

Schauen Sie zurück zum ursprünglichen Beispiel und beachten Sie die obigen Punkte:

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

Hier fooist ein Objekt und aist ein Attribut von foo(verfügbar unter foo.func_defs[0]). Da aist eine Liste, aist veränderlich und ist somit ein Lese- / Schreibattribut von foo. Es wird in der leeren Liste initialisiert, wie in der Signatur angegeben, wenn die Funktion instanziiert wird, und steht zum Lesen und Schreiben zur Verfügung, solange das Funktionsobjekt vorhanden ist.

Beim Aufrufen fooohne Überschreiben eines Standards wird der Wert dieses Standards von verwendet foo.func_defs. In diesem Fall foo.func_defs[0]wird ainnerhalb des Codebereichs des Funktionsobjekts verwendet. Änderungen an aÄnderungen foo.func_defs[0], die Teil des fooObjekts sind und zwischen der Ausführung des Codes in bestehen bleiben foo.

Vergleichen Sie dies nun mit dem Beispiel aus der Dokumentation zum Emulieren des Standardargumentverhaltens anderer Sprachen , sodass die Standardeinstellungen für die Funktionssignatur bei jeder Ausführung der Funktion verwendet werden:

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

Unter Berücksichtigung von (1) und (2) kann man sehen, warum dies das gewünschte Verhalten bewirkt:

• Wenn das fooFunktionsobjekt instanziiert wird, foo.func_defs[0]wird es auf Noneein unveränderliches Objekt gesetzt.
• Wenn die Funktion mit Standardwerten ausgeführt wird (ohne dass Lim Funktionsaufruf ein Parameter angegeben wurde ), ist foo.func_defs[0]( None) im lokalen Bereich als verfügbar L.
• Nach L = []kann die Zuweisung nicht erfolgreich sein foo.func_defs[0], da dieses Attribut schreibgeschützt ist.
• Per (1) , eine neue lokale Variable auch genannt Lim lokalen Bereich erstellt wird , und für den Rest des Funktionsaufrufes. foo.func_defs[0]bleibt somit für zukünftige Aufrufe von unverändert foo.

Ich werde eine alternative Struktur demonstrieren, um einen Standardlistenwert an eine Funktion zu übergeben (dies funktioniert genauso gut mit Wörterbüchern).

Wie andere ausführlich kommentiert haben, ist der Listenparameter an die Funktion gebunden, wenn er definiert ist, und nicht, wenn er ausgeführt wird. Da Listen und Wörterbücher veränderbar sind, wirkt sich jede Änderung dieses Parameters auf andere Aufrufe dieser Funktion aus. Infolgedessen erhalten nachfolgende Aufrufe der Funktion diese gemeinsam genutzte Liste, die möglicherweise durch andere Aufrufe der Funktion geändert wurde. Schlimmer noch, zwei Parameter verwenden gleichzeitig den gemeinsamen Parameter dieser Funktion, ohne die Änderungen zu berücksichtigen, die der andere vorgenommen hat.

Falsche Methode (wahrscheinlich ...) :

def foo(list_arg=[5]):
    return list_arg

a = foo()
a.append(6)
>>> a
[5, 6]

b = foo()
b.append(7)
# The value of 6 appended to variable 'a' is now part of the list held by 'b'.
>>> b
[5, 6, 7]  

# Although 'a' is expecting to receive 6 (the last element it appended to the list),
# it actually receives the last element appended to the shared list.
# It thus receives the value 7 previously appended by 'b'.
>>> a.pop()             
7

Sie können überprüfen, ob es sich um ein und dasselbe Objekt handelt, indem Sie Folgendes verwenden id:

>>> id(a)
5347866528

>>> id(b)
5347866528

Per Brett Slatkins "Effektives Python: 59 spezifische Möglichkeiten, besseres Python zu schreiben", Punkt 20: Verwenden Sie Noneund Docstrings, um dynamische Standardargumente anzugeben (S. 48).

Die Konvention zum Erreichen des gewünschten Ergebnisses in Python besteht darin, einen Standardwert von bereitzustellen Noneund das tatsächliche Verhalten in der Dokumentzeichenfolge zu dokumentieren.

Diese Implementierung stellt sicher, dass jeder Aufruf der Funktion entweder die Standardliste oder die an die Funktion übergebene Liste empfängt.

Bevorzugte Methode :

def foo(list_arg=None):
   """
   :param list_arg:  A list of input values. 
                     If none provided, used a list with a default value of 5.
   """
   if not list_arg:
       list_arg = [5]
   return list_arg

a = foo()
a.append(6)
>>> a
[5, 6]

b = foo()
b.append(7)
>>> b
[5, 7]

c = foo([10])
c.append(11)
>>> c
[10, 11]

Es kann legitime Anwendungsfälle für die 'Falsche Methode' geben, bei denen der Programmierer beabsichtigte, den Standardlistenparameter gemeinsam zu nutzen. Dies ist jedoch eher die Ausnahme als die Regel.

Die Lösungen hier sind:

1. Verwenden Sie Noneals Standardwert (oder als Nonce object) und aktivieren Sie diesen Wert , um Ihre Werte zur Laufzeit zu erstellen. oder
2. Verwenden Sie a lambdaals Standardparameter und rufen Sie es in einem try-Block auf, um den Standardwert abzurufen (für diese Art der Lambda-Abstraktion ist dies vorgesehen).

Die zweite Option ist hilfreich, da Benutzer der Funktion eine aufrufbare Datei übergeben können, die möglicherweise bereits vorhanden ist (z. B. a type).

Wenn wir das tun:

def foo(a=[]):
    ...

... ordnen wir das Argument aeiner unbenannten Liste zu, wenn der Aufrufer den Wert von a nicht übergibt.

Um die Diskussion zu vereinfachen, geben wir der unbenannten Liste vorübergehend einen Namen. Wie wäre es pavlo?

def foo(a=pavlo):
   ...

Wenn der Anrufer uns nicht sagt, was aist, können wir jederzeit wiederverwenden pavlo.

Wenn pavloes veränderbar (modifizierbar) ist und es fooletztendlich modifiziert, wird ein Effekt, den wir beim nächsten Mal bemerken foo, ohne Angabe aufgerufen a.

Das sehen Sie also (Denken Sie daran, pavlowird mit [] initialisiert):

 >>> foo()
 [5]

Nun pavloist [5].

Erneutes Aufrufen foo()ändert sich pavloerneut:

>>> foo()
[5, 5]

Die Angabe abeim Anrufen foo()stellt sicher, dass pavlonicht berührt wird.

>>> ivan = [1, 2, 3, 4]
>>> foo(a=ivan)
[1, 2, 3, 4, 5]
>>> ivan
[1, 2, 3, 4, 5]

Also pavloist es immer noch [5, 5].

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

Ich nutze dieses Verhalten manchmal als Alternative zum folgenden Muster:

singleton = None

def use_singleton():
    global singleton

    if singleton is None:
        singleton = _make_singleton()

    return singleton.use_me()

Wenn singletonnur von verwendet wird use_singleton, mag ich das folgende Muster als Ersatz:

# _make_singleton() is called only once when the def is executed
def use_singleton(singleton=_make_singleton()):
    return singleton.use_me()

Ich habe dies verwendet, um Clientklassen zu instanziieren, die auf externe Ressourcen zugreifen, und um Diktate oder Listen zum Auswendiglernen zu erstellen.

Da ich dieses Muster nicht für bekannt halte, füge ich einen kurzen Kommentar hinzu, um zukünftige Missverständnisse zu vermeiden.

Sie können dies umgehen, indem Sie das Objekt (und damit die Verbindung zum Zielfernrohr) ersetzen:

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

Hässlich, aber es funktioniert.

Es kann wahr sein, dass:

1. Jemand verwendet jede Sprach- / Bibliotheksfunktion und
2. Ein Wechsel des Verhaltens hier wäre aber nicht ratsam

Es ist völlig konsistent, an beiden oben genannten Merkmalen festzuhalten und noch einen weiteren Punkt hervorzuheben:

3. Es ist eine verwirrende Funktion und in Python unglücklich.

Die anderen Antworten oder zumindest einige von ihnen machen entweder Punkte 1 und 2, aber nicht 3, oder machen Punkt 3 und spielen die Punkte 1 und 2 herunter. Aber alle drei sind wahr.

Es mag wahr sein, dass das Wechseln von Pferden im Mittelstrom hier zu einem erheblichen Bruch führen würde und dass es weitere Probleme geben könnte, wenn Python so geändert wird, dass es intuitiv mit Stefanos Eröffnungsschnipsel umgeht. Und es kann wahr sein, dass jemand, der Python-Interna gut kannte, ein Minenfeld von Konsequenzen erklären könnte. Jedoch,

Das vorhandene Verhalten ist nicht pythonisch, und Python ist erfolgreich, da nur sehr wenig über die Sprache das Prinzip des geringsten Erstaunens verletzt Näheso schlecht. Es ist ein echtes Problem, ob es sinnvoll wäre, es zu entwurzeln oder nicht. Es ist ein Designfehler. Wenn Sie die Sprache viel besser verstehen, indem Sie versuchen, das Verhalten aufzuspüren, kann ich sagen, dass C ++ all dies und mehr tut. Sie lernen viel, indem Sie beispielsweise durch subtile Zeigerfehler navigieren. Dies ist jedoch nicht Pythonic: Menschen, die sich genug für Python interessieren, um angesichts dieses Verhaltens durchzuhalten, sind Menschen, die von der Sprache angezogen werden, weil Python weit weniger Überraschungen als andere Sprachen hat. Dabbler und Neugierige werden zu Pythonisten, wenn sie erstaunt sind, wie wenig Zeit benötigt wird, um etwas zum Laufen zu bringen - nicht wegen eines Design-Fl - ich meine, versteckten Logik-Puzzles -, das gegen die Intuitionen von Programmierern verstößt, die sich für Python interessieren weil es einfach funktioniert .

Dies ist kein Konstruktionsfehler . Wer darüber stolpert, macht etwas falsch.

Ich sehe 3 Fälle, in denen Sie auf dieses Problem stoßen könnten:

1. Sie beabsichtigen, das Argument als Nebeneffekt der Funktion zu ändern. In diesem Fall ist es niemals sinnvoll , ein Standardargument zu haben. Die einzige Ausnahme ist, wenn Sie die Argumentliste missbrauchen, um beispielsweise Funktionsattribute zu haben cache={}, und von Ihnen nicht erwartet wird, dass Sie die Funktion mit einem tatsächlichen Argument aufrufen.
2. Sie beabsichtigen , das Argument unmodifizierten zu verlassen, aber Sie versehentlich haben es zu ändern. Das ist ein Fehler, behebe ihn.
3. Sie wollten das Argument für die Verwendung innerhalb der Funktion ändern, haben jedoch nicht erwartet, dass die Änderung außerhalb der Funktion angezeigt werden kann. In diesem Fall müssen Sie eine Kopie des Arguments erstellen, unabhängig davon, ob es die Standardeinstellung war oder nicht! Python ist keine Call-by-Value-Sprache, daher wird die Kopie nicht für Sie erstellt. Sie müssen dies explizit angeben.

Das Beispiel in der Frage könnte in Kategorie 1 oder 3 fallen. Es ist seltsam, dass sowohl die übergebene Liste geändert als auch zurückgegeben wird. Sie sollten den einen oder anderen auswählen.

Dieser "Fehler" gab mir viele Überstunden! Aber ich fange an, eine mögliche Verwendung davon zu sehen (aber ich hätte es mir gewünscht, dass es immer noch zur Ausführungszeit ist)

Ich werde Ihnen das geben, was ich als nützliches Beispiel sehe.

def example(errors=[]):
    # statements
    # Something went wrong
    mistake = True
    if mistake:
        tryToFixIt(errors)
        # Didn't work.. let's try again
        tryToFixItAnotherway(errors)
        # This time it worked
    return errors

def tryToFixIt(err):
    err.append('Attempt to fix it')

def tryToFixItAnotherway(err):
    err.append('Attempt to fix it by another way')

def main():
    for item in range(2):
        errors = example()
    print '\n'.join(errors)

main()

druckt Folgendes aus

Attempt to fix it
Attempt to fix it by another way
Attempt to fix it
Attempt to fix it by another way

Ändern Sie einfach die Funktion wie folgt:

def notastonishinganymore(a = []): 
    '''The name is just a joke :)'''
    a = a[:]
    a.append(5)
    return a

Ich denke, die Antwort auf diese Frage liegt darin, wie Python Daten an Parameter übergibt (Übergabe nach Wert oder Referenz), nicht nach Veränderbarkeit oder wie Python mit der Anweisung "def" umgeht.

Eine kurze Einführung. Erstens gibt es in Python zwei Arten von Datentypen, einen einfachen elementaren Datentyp wie Zahlen und einen anderen Datentyp Objekte. Zweitens übergibt Python beim Übergeben von Daten an Parameter den elementaren Datentyp nach Wert, dh erstellt eine lokale Kopie des Werts an eine lokale Variable, übergibt jedoch das Objekt als Referenz, dh Zeiger auf das Objekt.

Lassen Sie uns unter Berücksichtigung der beiden oben genannten Punkte erklären, was mit dem Python-Code passiert ist. Dies liegt nur daran, dass Objekte als Referenz übergeben werden, hat aber nichts mit veränderlichen / unveränderlichen oder wohl der Tatsache zu tun, dass die Anweisung "def" nur einmal ausgeführt wird, wenn sie definiert ist.

[] ist ein Objekt, daher übergibt Python die Referenz von [] an a, dh es aist nur ein Zeiger auf [], der als Objekt im Speicher liegt. Es gibt nur eine Kopie von [] mit vielen Verweisen darauf. Für das erste foo () wird die Liste [] durch die Append-Methode in 1 geändert . Beachten Sie jedoch, dass es nur eine Kopie des Listenobjekts gibt und dieses Objekt jetzt zu 1 wird . Beim Ausführen des zweiten foo () ist die Aussage der effbot-Webseite (Elemente werden nicht mehr ausgewertet) falsch. awird als Listenobjekt ausgewertet, obwohl der Inhalt des Objekts jetzt 1 ist . Dies ist der Effekt der Referenzübergabe! Das Ergebnis von foo (3) kann auf die gleiche Weise leicht abgeleitet werden.

Um meine Antwort weiter zu validieren, werfen wir einen Blick auf zwei zusätzliche Codes.

====== Nr. 2 ========

def foo(x, items=None):
    if items is None:
        items = []
    items.append(x)
    return items

foo(1)  #return [1]
foo(2)  #return [2]
foo(3)  #return [3]

[]ist ein Objekt, so ist es None(das erstere ist veränderlich, während das letztere unveränderlich ist. Aber die Veränderlichkeit hat nichts mit der Frage zu tun). Keiner ist irgendwo im Raum, aber wir wissen, dass er da ist und es gibt nur eine Kopie von Keiner dort. Jedes Mal, wenn foo aufgerufen wird, werden Elemente bewertet (im Gegensatz zu einer Antwort, die nur einmal ausgewertet wird), um Keine zu sein, um klar zu sein, die Referenz (oder die Adresse) von Keine. Dann wird im foo das Element in [] geändert, dh es zeigt auf ein anderes Objekt, das eine andere Adresse hat.

====== Nr. 3 =======

def foo(x, items=[]):
    items.append(x)
    return items

foo(1)    # returns [1]
foo(2,[]) # returns [2]
foo(3)    # returns [1,3]

Durch den Aufruf von foo (1) verweisen Elemente auf ein Listenobjekt [] mit einer Adresse, z. B. 11111111. Der Inhalt der Liste wird in der foo-Funktion in der Folge auf 1 geändert, die Adresse wird jedoch nicht geändert, immer noch 11111111 Dann kommt foo (2, []). Obwohl das [] in foo (2, []) beim Aufrufen von foo (1) den gleichen Inhalt wie der Standardparameter [] hat, sind ihre Adressen unterschiedlich! Da wir den Parameter explizit angeben, itemsmuss die Adresse dieses neuen übernommen werden[] angeben , z. B. 2222222, übernommen und nach einigen Änderungen zurückgegeben werden. Jetzt wird foo (3) ausgeführt. seit Nurxbereitgestellt wird, müssen Elemente wieder ihren Standardwert annehmen. Was ist der Standardwert? Sie wird beim Definieren der Funktion foo festgelegt: das in 11111111 befindliche Listenobjekt. Die Elemente werden also als Adresse 11111111 mit einem Element 1 ausgewertet. Die Liste in 2222222 enthält ebenfalls ein Element 2, wird jedoch nicht von Elementen angezeigt Mehr. Folglich ergibt ein Anhang von 3 items[1,3].

Aus den obigen Erklärungen können wir ersehen, dass die in der akzeptierten Antwort empfohlene Effbot- Webseite keine relevante Antwort auf diese Frage gab. Darüber hinaus denke ich, dass ein Punkt auf der Effbot-Webseite falsch ist. Ich denke, der Code bezüglich der Benutzeroberfläche ist korrekt:

for i in range(10):
    def callback():
        print "clicked button", i
    UI.Button("button %s" % i, callback)

Jede Taste kann eine eigene Rückruffunktion enthalten, die einen anderen Wert von anzeigt i. Ich kann ein Beispiel geben, um dies zu zeigen:

x=[]
for i in range(10):
    def callback():
        print(i)
    x.append(callback) 

Wenn wir ausführen, erhalten x[7]()wir wie erwartet 7 und x[9]()geben 9, einen weiteren Wert von i.

TLDR: Standardeinstellungen für die Definitionszeit sind konsistent und streng aussagekräftiger.

Das Definieren einer Funktion wirkt sich auf zwei Bereiche aus: den definierenden Bereich , der die Funktion enthält, und den Ausführungsbereich , der in der Funktion enthalten ist. Während es ziemlich klar ist, wie Blöcke Bereichen zugeordnet werden, ist die Frage, wo sie def <name>(<args=defaults>):hingehören:

...                           # defining scope
def name(parameter=default):  # ???
    ...                       # execution scope

Das def nameTeil muss im definierenden Bereich ausgewertet werden - wir wollen nameschließlich dort verfügbar sein. Wenn die Funktion nur in sich selbst ausgewertet wird, ist sie nicht mehr zugänglich.

Da parameteres sich um einen konstanten Namen handelt, können wir ihn gleichzeitig mit "auswerten" def name. Dies hat auch den Vorteil, dass die Funktion mit einer bekannten Signatur name(parameter=...):anstelle einer bloßen Signatur erzeugt wird name(...):.

Wann ist zu bewerten default?

Konsistenz sagt bereits "bei Definition": Alles andere von def <name>(<args=defaults>):wird am besten auch bei Definition bewertet. Teile davon zu verzögern wäre die erstaunliche Wahl.

Die beiden Auswahlmöglichkeiten sind auch nicht gleichwertig: Wenn sie defaultzur Definitionszeit ausgewertet werden, kann dies immer noch die Ausführungszeit beeinflussen. Wenn defaultes zur Ausführungszeit ausgewertet wird, kann es die Definitionszeit nicht beeinflussen. Wenn Sie "bei Definition" auswählen, können beide Fälle ausgedrückt werden, während bei Auswahl von "bei Ausführung" nur einer ausgedrückt werden kann:

def name(parameter=defined):  # set default at definition time
    ...

def name(parameter=default):     # delay default until execution time
    parameter = default if parameter is None else parameter
    ...

Jede andere Antwort erklärt, warum dies eigentlich ein nettes und gewünschtes Verhalten ist oder warum Sie dies sowieso nicht brauchen sollten. Meins ist für diejenigen, die hartnäckig sind und ihr Recht ausüben wollen, die Sprache nach ihrem Willen zu beugen, nicht umgekehrt.

Wir werden dieses Verhalten mit einem Dekorateur "beheben", der den Standardwert kopiert, anstatt dieselbe Instanz für jedes Positionsargument wiederzuverwenden, das auf seinem Standardwert belassen wird.

import inspect
from copy import copy

def sanify(function):
    def wrapper(*a, **kw):
        # store the default values
        defaults = inspect.getargspec(function).defaults # for python2
        # construct a new argument list
        new_args = []
        for i, arg in enumerate(defaults):
            # allow passing positional arguments
            if i in range(len(a)):
                new_args.append(a[i])
            else:
                # copy the value
                new_args.append(copy(arg))
        return function(*new_args, **kw)
    return wrapper

Definieren wir nun unsere Funktion mit diesem Dekorator neu:

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

foo() # '[5]'
foo() # '[5]' -- as desired

Dies ist besonders praktisch für Funktionen, die mehrere Argumente annehmen. Vergleichen Sie:

# the 'correct' approach
def bar(a=None, b=None, c=None):
    if a is None:
        a = []
    if b is None:
        b = []
    if c is None:
        c = []
    # finally do the actual work

mit

# the nasty decorator hack
@sanify
def bar(a=[], b=[], c=[]):
    # wow, works right out of the box!

Es ist wichtig zu beachten, dass die obige Lösung nicht funktioniert, wenn Sie versuchen, Keyword-Argumente wie folgt zu verwenden:

foo(a=[4])

Der Dekorateur könnte angepasst werden, um dies zu ermöglichen, aber wir überlassen dies dem Leser als Übung;)