Cualquiera que haya jugado con Python el tiempo suficiente ha sido mordido (o despedazado) por el siguiente problema:

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

Principiantes de Python que se esperan esta función para volver siempre una lista con un solo elemento: [5]. El resultado es, en cambio, muy diferente y muy sorprendente (para un novato):

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

Un gerente mío tuvo una vez su primer encuentro con esta característica, y lo calificó como "una falla dramática en el diseño" del lenguaje. Respondí que el comportamiento tenía una explicación subyacente, y de hecho es muy desconcertante e inesperado si no entiendes lo interno. Sin embargo, no pude responder (a mí mismo) la siguiente pregunta: ¿cuál es la razón para vincular el argumento predeterminado en la definición de la función y no en la ejecución de la función? Dudo que el comportamiento experimentado tenga un uso práctico (¿quién realmente usó variables estáticas en C, sin criar insectos?)

Editar :

Baczek hizo un ejemplo interesante. Junto con la mayoría de sus comentarios y los de Utaal en particular, elaboré más:

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

Para mí, parece que la decisión de diseño fue relativa a dónde poner el alcance de los parámetros: dentro de la función o "junto" con ella?

Hacer el enlace dentro de la función significaría que xestá efectivamente vinculado al valor predeterminado especificado cuando se llama a la función, no está definida, algo que presentaría un defecto profundo: la deflínea sería "híbrida" en el sentido de que parte del enlace (de el objeto de función) sucedería en la definición, y parte (asignación de parámetros predeterminados) en el momento de invocación de la función.

El comportamiento real es más consistente: todo lo de esa línea se evalúa cuando se ejecuta esa línea, es decir, en la definición de la función.

En realidad, esto no es un defecto de diseño, y no se debe a aspectos internos o de rendimiento.
Viene simplemente del hecho de que las funciones en Python son objetos de primera clase, y no solo un fragmento de código.

Tan pronto como llegue a pensar de esta manera, tiene sentido completamente: una función es un objeto que se evalúa en su definición; los parámetros predeterminados son una especie de "datos de miembros" y, por lo tanto, su estado puede cambiar de una llamada a otra, exactamente como en cualquier otro objeto.

En cualquier caso, Effbot tiene una muy buena explicación de las razones de este comportamiento en los valores de parámetros predeterminados en Python .
Lo encontré muy claro, y realmente sugiero leerlo para conocer mejor cómo funcionan los objetos de función.

Supongamos que tiene el siguiente código

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

def eat(food=fruits):
    ...

Cuando veo la declaración de comer, lo menos sorprendente es pensar que si no se da el primer parámetro, será igual a la tupla ("apples", "bananas", "loganberries")

Sin embargo, supuestamente más adelante en el código, hago algo como

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

entonces, si los parámetros predeterminados se vincularon en la ejecución de la función en lugar de la declaración de la función, me sorprendería (de una manera muy mala) descubrir que las frutas habían cambiado. Esto sería más sorprendente IMO que descubrir que su foofunción anterior estaba mutando la lista.

El verdadero problema radica en las variables mutables, y todos los idiomas tienen este problema hasta cierto punto. Aquí hay una pregunta: supongamos que en Java tengo el siguiente código:

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?

Ahora, ¿utiliza mi mapa el valor de la StringBufferclave cuando se colocó en el mapa, o almacena la clave por referencia? De cualquier manera, alguien está asombrado; o la persona que trató de sacar el objeto Mapusando un valor idéntico al que lo colocó, o la persona que parece no poder recuperar su objeto a pesar de que la clave que está usando es literalmente el mismo objeto eso se usó para ponerlo en el mapa (esta es la razón por la cual Python no permite que sus tipos de datos incorporados mutables se usen como claves de diccionario).

Su ejemplo es un buen caso en el que los recién llegados a Python serán sorprendidos y mordidos. Pero yo diría que si "solucionáramos" esto, entonces eso solo crearía una situación diferente en la que serían mordidos, y esa sería aún menos intuitiva. Además, este es siempre el caso cuando se trata de variables mutables; siempre te encuentras con casos en los que alguien puede esperar intuitivamente uno o el comportamiento opuesto dependiendo del código que esté escribiendo.

Personalmente, me gusta el enfoque actual de Python: los argumentos de la función predeterminada se evalúan cuando se define la función y ese objeto es siempre el predeterminado. Supongo que podrían usar mayúsculas y minúsculas usando una lista vacía, pero ese tipo de carcasa especial causaría aún más asombro, sin mencionar que sería incompatible al revés.

La parte relevante de la documentación :

Los valores de los parámetros predeterminados se evalúan de izquierda a derecha cuando se ejecuta la definición de la función. Esto significa que la expresión se evalúa una vez, cuando se define la función, y que se utiliza el mismo valor "precalculado" para cada llamada. Esto es especialmente importante de entender cuando un parámetro predeterminado es un objeto mutable, como una lista o un diccionario: si la función modifica el objeto (por ejemplo, al agregar un elemento a una lista), el valor predeterminado se modifica en efecto. Esto generalmente no es lo que se pretendía. Una forma de evitar esto es usarlo Nonepor defecto y probarlo explícitamente en el cuerpo de la función, por ejemplo:

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

No sé nada sobre el funcionamiento interno del intérprete de Python (y tampoco soy un experto en compiladores e intérpretes), así que no me culpen si propongo algo insensible o imposible.

Siempre que los objetos de Python sean mutables , creo que esto debe tenerse en cuenta al diseñar los elementos de argumentos predeterminados. Cuando crea una instancia de una lista:

a = []

espera obtener una nueva lista referenciada por a.

¿Por qué debería el a=[]en

def x(a=[]):

instanciar una nueva lista en la definición de la función y no en la invocación? Es como si estuviera preguntando "si el usuario no proporciona el argumento, cree una nueva lista y úsela como si hubiera sido producida por la persona que llama". Creo que esto es ambiguo en su lugar:

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

usuario, ¿desea apredeterminar la fecha y hora correspondiente a cuando está definiendo o ejecutando x? En este caso, como en el anterior, mantendré el mismo comportamiento que si el argumento predeterminado "asignación" fuera la primera instrucción de la función ( datetime.now()llamada a la invocación de la función). Por otro lado, si el usuario quisiera el mapeo del tiempo de definición, podría escribir:

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

Lo sé, lo sé: eso es un cierre. Alternativamente, Python podría proporcionar una palabra clave para forzar el enlace de tiempo de definición:

def x(static a=b):

Bueno, la razón es simplemente que los enlaces se realizan cuando se ejecuta el código, y la definición de la función se ejecuta, bueno ... cuando se definen las funciones.

Compara esto:

class BananaBunch:
    bananas = []

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

Este código sufre exactamente la misma casualidad inesperada. bananas es un atributo de clase y, por lo tanto, cuando le agrega cosas, se agrega a todas las instancias de esa clase. La razón es exactamente la misma.

Es solo "Cómo funciona", y hacer que funcione de manera diferente en el caso de la función probablemente sería complicado, y en el caso de la clase probablemente imposible, o al menos ralentizaría mucho la creación de instancias de objetos, ya que tendría que mantener el código de la clase alrededor y ejecutarlo cuando se crean objetos.

Si, es inesperado. Pero una vez que el centavo cae, encaja perfectamente con cómo funciona Python en general. De hecho, es una buena ayuda para la enseñanza, y una vez que comprenda por qué sucede esto, comprenderá Python mucho mejor.

Dicho esto, debería ocupar un lugar destacado en cualquier buen tutorial de Python. Porque como mencionas, todos se encuentran con este problema tarde o temprano.

¿Por qué no introspectivas?

Estoy realmente sorprendido de que nadie haya realizado la perspicaz introspección ofrecida por Python ( 2y 3aplicar) en las llamadas.

Dada una pequeña función simple funcdefinida como:

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

Cuando Python lo encuentra, lo primero que hará es compilarlo para crear un codeobjeto para esta función. Mientras se realiza este paso de compilación, Python evalúa * y luego almacena los argumentos predeterminados (una lista vacía []aquí) en el propio objeto de función . Como se menciona en la respuesta principal: la lista aahora puede considerarse un miembro de la función func.

Entonces, hagamos una introspección, un antes y un después para examinar cómo se expande la lista dentro del objeto de función. Estoy usando Python 3.xpara esto, para Python 2 lo mismo se aplica (uso __defaults__o func_defaultsen Python 2; sí, dos nombres para la misma cosa).

Función antes de la ejecución:

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

Después de que Python ejecute esta definición, tomará los parámetros predeterminados especificados ( a = []aquí) y los agrupará en el __defaults__atributo para el objeto de función (sección relevante: Callables):

>>> func.__defaults__
([],)

Ok, entonces una lista vacía como entrada única __defaults__, tal como se esperaba.

Función después de la ejecución:

Ahora ejecutemos esta función:

>>> func()

Ahora, veamos esos de __defaults__nuevo:

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

¿Asombrado? ¡El valor dentro del objeto cambia! Las llamadas consecutivas a la función ahora simplemente se agregarán a ese listobjeto incrustado :

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

Entonces, ahí lo tiene, la razón por la que ocurre este 'defecto' es porque los argumentos predeterminados son parte del objeto de función. Aquí no pasa nada extraño, todo es un poco sorprendente.

La solución común para combatir esto es usar Nonecomo predeterminado y luego inicializar en el cuerpo de la función:

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

Dado que el cuerpo de la función se ejecuta de nuevo cada vez, siempre se obtiene una nueva lista vacía nueva si no se pasó ningún argumento a.

Para verificar aún más que la lista en __defaults__es la misma que la utilizada en la función func, simplemente puede cambiar su función para devolver idla lista autilizada dentro del cuerpo de la función. Luego, compárelo con la lista en __defaults__(posición [0]en __defaults__) y verá cómo se refieren a la misma instancia de lista:

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

¡Todo con el poder de la introspección!

^* Para verificar que Python evalúa los argumentos predeterminados durante la compilación de la función, intente ejecutar lo siguiente:

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

como notará, input()se llama antes del proceso de construcción de la función y se vincula al nombre bar.

Solía ​​pensar que crear los objetos en tiempo de ejecución sería el mejor enfoque. Ahora estoy menos seguro, ya que pierdes algunas características útiles, aunque puede valer la pena, independientemente de simplemente evitar la confusión del novato. Las desventajas de hacerlo son:

1. Rendimiento

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

Si se usa la evaluación del tiempo de llamada, entonces se llama a la función costosa cada vez que se usa su función sin un argumento. Pagaría un precio costoso en cada llamada o necesitaría almacenar manualmente el valor en la memoria externa, contaminando su espacio de nombres y agregando verbosidad.

2. Forzar parámetros vinculados

Un truco útil es vincular los parámetros de un lambda al enlace actual de una variable cuando se crea el lambda. Por ejemplo:

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

Esto devuelve una lista de funciones que devuelven 0,1,2,3 ... respectivamente. Si se cambia el comportamiento, en su lugar se unirán ial valor de tiempo de llamada de i, por lo que obtendría una lista de funciones que todos devuelven 9.

La única forma de implementar esto de otra manera sería crear un cierre adicional con el límite i, es decir:

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

3. Introspección

Considera el código:

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

Podemos obtener información sobre los argumentos y valores predeterminados utilizando el inspectmódulo, que

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

Esta información es muy útil para cosas como la generación de documentos, metaprogramación, decoradores, etc.

Ahora, suponga que el comportamiento de los valores predeterminados podría modificarse para que esto sea equivalente a:

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

Sin embargo, hemos perdido la capacidad de introspección y ver cuáles son los argumentos predeterminados . Debido a que los objetos no se han construido, no podemos obtenerlos sin llamar a la función. Lo mejor que podemos hacer es almacenar el código fuente y devolverlo como una cadena.

5 puntos en defensa de Python

1. Simplicidad : el comportamiento es simple en el siguiente sentido: la mayoría de las personas caen en esta trampa solo una vez, no varias.

2. Consistencia : Python siempre pasa objetos, no nombres. El parámetro predeterminado es, obviamente, parte del encabezado de la función (no el cuerpo de la función). Por lo tanto, debe evaluarse en el tiempo de carga del módulo (y solo en el tiempo de carga del módulo, a menos que esté anidado), no en el momento de la llamada a la función.

3. Utilidad : Como señala Frederik Lundh en su explicación de "Valores de parámetros predeterminados en Python" , el comportamiento actual puede ser bastante útil para la programación avanzada. (Utilizar con moderación.)

4. Documentación suficiente : en la documentación más básica de Python, el tutorial, el problema se anuncia en voz alta como una "Advertencia importante" en la primera subsección de la Sección "Más sobre la definición de funciones" . La advertencia incluso usa negrita, que rara vez se aplica fuera de los encabezados. RTFM: lea el excelente manual.

5. Meta-aprendizaje : caer en la trampa es en realidad un momento muy útil (al menos si eres un estudiante reflexivo), porque posteriormente comprenderás mejor el punto "Consistencia" anterior y eso te enseñará mucho sobre Python.

Este comportamiento se explica fácilmente por:

1. La declaración de función (clase, etc.) se ejecuta solo una vez, creando todos los objetos de valor predeterminado
2. todo pasa por referencia

Entonces:

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

1. a no cambia - cada llamada de asignación crea un nuevo objeto int - se imprime un nuevo objeto
2. b no cambia: la nueva matriz se crea a partir del valor predeterminado y se imprime
3. c cambios - la operación se realiza en el mismo objeto - y se imprime

Lo que estás preguntando es por qué esto:

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

no es internamente equivalente a esto:

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

a excepción del caso de llamar explícitamente a func (None, None), que ignoraremos.

En otras palabras, en lugar de evaluar los parámetros predeterminados, ¿por qué no almacenar cada uno de ellos y evaluarlos cuando se llama a la función?

Probablemente haya una respuesta: convertiría efectivamente todas las funciones con parámetros predeterminados en un cierre. Incluso si todo está oculto en el intérprete y no un cierre completo, los datos deben almacenarse en algún lugar. Sería más lento y usaría más memoria.

1) El llamado problema del "Argumento predeterminado mutable" es en general un ejemplo especial que demuestra que:
"Todas las funciones con este problema también sufren un problema de efectos secundarios similar en el parámetro real ",
eso va en contra de las reglas de la programación funcional, por lo general, no se puede despreciar y se deben arreglar juntos.

Ejemplo:

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]

Solución : una copia
una solución absolutamente seguro es que copyni deepcopyel objeto de entrada primero y luego hacer lo que sea con la copia.

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

Muchos tipos mutables incorporados tienen un método de copia como some_dict.copy()osome_set.copy() , o se pueden copiar fácilmente como somelist[:]o list(some_list). Cada objeto también puede ser copiado copy.copy(any_object)o más completo por copy.deepcopy()(este último útil si el objeto mutable está compuesto de objetos mutables). Algunos objetos se basan fundamentalmente en efectos secundarios como el objeto "archivo" y no se pueden reproducir de manera significativa mediante copia. proceso de copiar

Problema de ejemplo para una pregunta SO similar

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]

No se debe guardar ni guardar en ninguna atributo público de una instancia devuelta por esta función. (Suponiendo que los atributos privados de instancia no se deben modificar desde fuera de esta clase o subclases por convención. Es decir, _var1es un atributo privado)

Conclusión:
objetos de parámetros de entrada no deben modificarse en su lugar (mutar) ni tampoco deben vincularse a un objeto devuelto por la función. (Si preferimos la programación sin efectos secundarios, lo cual es muy recomendable. Ver Wiki sobre "efectos secundarios" (Los dos primeros párrafos son relevantes en este contexto).)

2)
Solo si el efecto secundario sobre el parámetro real es requerido pero no deseado en el parámetro predeterminado, entonces la solución útil esdef ...(var1=None): if var1 is None: var1 = [] Más ...

3) En algunos casos es útil el comportamiento mutable de los parámetros predeterminados .

En realidad, esto no tiene nada que ver con los valores predeterminados, aparte de que a menudo aparece como un comportamiento inesperado al escribir funciones con valores predeterminados mutables.

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

No hay valores predeterminados a la vista en este código, pero obtiene exactamente el mismo problema.

El problema es que fooestá modificando una variable mutable transmitida por la persona que llama, cuando la persona que llama no espera esto. Un código como este estaría bien si la función se llamara algo así append_5; entonces la persona que llama llamaría a la función para modificar el valor que pasa y se esperaría el comportamiento. Pero es muy poco probable que una función de este tipo tome un argumento predeterminado, y probablemente no devolverá la lista (ya que la persona que llama ya tiene una referencia a esa lista; la que acaba de pasar).

Su original foo, con un argumento predeterminado, no debería modificar asi se pasó explícitamente o si obtuvo el valor predeterminado. Su código debe dejar solo argumentos mutables a menos que sea claro por el contexto / nombre / documentación que se supone que los argumentos deben ser modificados. Usar valores mutables pasados ​​como argumentos como temporarios locales es una idea extremadamente mala, ya sea que estemos en Python o no y si hay argumentos predeterminados involucrados o no.

Si necesita manipular destructivamente un temporal local en el curso de calcular algo, y necesita comenzar su manipulación desde un valor de argumento, debe hacer una copia.

Tema ya ocupado, pero por lo que leí aquí, lo siguiente me ayudó a darme cuenta de cómo funciona internamente:

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 una optimización de rendimiento. Como resultado de esta funcionalidad, ¿cuál de estas dos llamadas a funciones cree que es más rápida?

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

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

Te daré una pista. Aquí está el desmontaje (ver 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

Dudo que el comportamiento experimentado tenga un uso práctico (¿quién realmente usó variables estáticas en C, sin criar insectos?)

Como se puede ver, no es una ventaja en el rendimiento cuando se usan parámetros por defecto inmutables. Esto puede marcar la diferencia si es una función llamada con frecuencia o si el argumento predeterminado tarda mucho en construirse. Además, tenga en cuenta que Python no es C. En C tiene constantes que son prácticamente gratuitas. En Python no tienes este beneficio.

Python: el argumento predeterminado mutable

Los argumentos predeterminados se evalúan en el momento en que la función se compila en un objeto de función. Cuando es utilizada por la función, varias veces por esa función, son y siguen siendo el mismo objeto.

Cuando son mutables, cuando mutan (por ejemplo, al agregarle un elemento) permanecen mutados en llamadas consecutivas.

Permanecen mutados porque son el mismo objeto cada vez.

Código equivalente

Dado que la lista está vinculada a la función cuando el objeto de función se compila y se instancia, esto:

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

es casi exactamente equivalente a esto:

_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

Demostración

Aquí hay una demostración: puede verificar que son el mismo objeto cada vez que los hace referencia

• viendo que la lista se crea antes de que la función haya terminado de compilarse en un objeto de función,
• observando que la identificación es la misma cada vez que se hace referencia a la lista,
• observando que la lista permanece cambiada cuando la función que la usa se llama por segunda vez,
• observando el orden en que se imprime la salida desde la fuente (que convenientemente numeré para usted):

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

y ejecutarlo con 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']

¿Esto viola el principio de "Menos asombro"?

Este orden de ejecución es frecuentemente confuso para los nuevos usuarios de Python. Si comprende el modelo de ejecución de Python, entonces se vuelve bastante esperado.

La instrucción habitual para los nuevos usuarios de Python:

Pero esta es la razón por la cual la instrucción habitual para los nuevos usuarios es crear sus argumentos predeterminados como este:

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

Esto usa el singleton None como un objeto centinela para decirle a la función si hemos recibido o no un argumento diferente al predeterminado. Si no obtenemos argumentos, en realidad queremos usar una nueva lista vacía [], como valor predeterminado.

Como dice la sección del tutorial sobre el flujo de control :

Si no desea que el valor predeterminado se comparta entre llamadas posteriores, puede escribir la función de esta manera:

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

La respuesta más corta probablemente sería "definición es ejecución", por lo tanto, todo el argumento no tiene sentido estricto. Como un ejemplo más artificial, puedes citar esto:

def a(): return []

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

Con suerte, es suficiente para mostrar que no ejecutar las expresiones de argumento predeterminadas en el momento de la ejecución de la defdeclaración no es fácil o no tiene sentido, o ambos.

Sin embargo, estoy de acuerdo en que es un problema cuando intentas usar constructores predeterminados.

Una solución simple usando 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]

Este comportamiento no es sorprendente si tiene en cuenta lo siguiente:

1. El comportamiento de los atributos de clase de solo lectura en los intentos de asignación, y que
2. Las funciones son objetos (explicados bien en la respuesta aceptada).

El papel de (2) se ha cubierto ampliamente en este hilo. (1) es probablemente el factor causante de asombro, ya que este comportamiento no es "intuitivo" cuando proviene de otros idiomas.

(1) se describe en el tutorial de Python sobre clases . En un intento de asignar un valor a un atributo de clase de solo lectura:

... todas las variables que se encuentran fuera del ámbito más interno son de solo lectura ( un intento de escribir en dicha variable simplemente creará una nueva variable local en el ámbito más interno, dejando la variable externa con el mismo nombre sin cambios ).

Vuelva al ejemplo original y considere los puntos anteriores:

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

Aquí foohay un objeto y aes un atributo de foo(disponible en foo.func_defs[0]). Dado que aes una lista, aes mutable y, por lo tanto, es un atributo de lectura-escritura de foo. Se inicializa en la lista vacía según lo especificado por la firma cuando se instancia la función, y está disponible para leer y escribir mientras exista el objeto de función.

Llamar foosin anular un valor predeterminado utiliza el valor de ese valor predeterminado foo.func_defs. En este caso, foo.func_defs[0]se utiliza para ael alcance del código del objeto de función. Cambios a acambio foo.func_defs[0], que es parte del fooobjeto y persiste entre la ejecución del código en foo.

Ahora, compare esto con el ejemplo de la documentación sobre la emulación del comportamiento de argumento predeterminado de otros idiomas , de modo que los valores predeterminados de la firma de la función se usen cada vez que se ejecuta la función:

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

Teniendo en cuenta (1) y (2) , uno puede ver por qué esto logra el comportamiento deseado:

• Cuando se crea una fooinstancia del objeto de función, foo.func_defs[0]se establece en Noneun objeto inmutable.
• Cuando la función se ejecuta con los valores predeterminados (sin ningún parámetro especificado Len la llamada a la función), foo.func_defs[0]( None) está disponible en el ámbito local como L.
• Tras L = [], la asignación no puede tener éxito en foo.func_defs[0], porque ese atributo es de solo lectura.
• Por (1) , una nueva variable local también nombrada Lse crea en el ámbito local y se utiliza para el resto de la llamada a la función. foo.func_defs[0]así permanece sin cambios para futuras invocaciones de foo.

Voy a demostrar una estructura alternativa para pasar un valor de lista predeterminado a una función (funciona igualmente bien con los diccionarios).

Como otros han comentado extensamente, el parámetro de lista está vinculado a la función cuando se define y no cuando se ejecuta. Debido a que las listas y los diccionarios son mutables, cualquier modificación a este parámetro afectará otras llamadas a esta función. Como resultado, las llamadas posteriores a la función recibirán esta lista compartida que puede haber sido alterada por cualquier otra llamada a la función. Peor aún, dos parámetros están utilizando el parámetro compartido de esta función al mismo tiempo ajeno a los cambios realizados por el otro.

Método incorrecto (probablemente ...) :

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

Puede verificar que son el mismo objeto usando id:

>>> id(a)
5347866528

>>> id(b)
5347866528

Según "Python eficaz: 59 formas específicas de escribir mejor Python" de Brett Slatkin, Elemento 20: Uso Noney cadenas de documentos para especificar argumentos dinámicos predeterminados (p. 48)

La convención para lograr el resultado deseado en Python es proporcionar un valor predeterminado Noney documentar el comportamiento real en la cadena de documentación.

Esta implementación garantiza que cada llamada a la función reciba la lista predeterminada o la lista que se pasa a la función.

Método preferido :

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]

Puede haber casos de uso legítimos para el 'Método incorrecto' por el cual el programador pretendía que se compartiera el parámetro de lista predeterminado, pero es más probable que sea la excepción que la regla.

Las soluciones aquí son:

1. Úselo Nonecomo su valor predeterminado (o un nonce object) y actívelo para crear sus valores en tiempo de ejecución; o
2. Use a lambdacomo parámetro predeterminado y llámelo dentro de un bloque try para obtener el valor predeterminado (este es el tipo de cosa para la que sirve la abstracción lambda).

La segunda opción es buena porque los usuarios de la función pueden pasar un invocable, que ya puede existir (como a type)

Cuando hacemos esto:

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

... asignamos el argumento aa un sin nombre lista , si la persona que llama no pasa el valor de a.

Para simplificar las cosas para esta discusión, le daremos temporalmente un nombre a la lista sin nombre. ¿Qué tal pavlo?

def foo(a=pavlo):
   ...

En cualquier momento, si la persona que llama no nos dice qué aes, lo reutilizamos pavlo.

Si pavloes mutable (modificable) y footermina modificándolo, un efecto que notamos la próxima vez foose llama sin especificar a.

Entonces esto es lo que ves (recuerda, pavlose inicializa a []):

 >>> foo()
 [5]

Ahora, pavloes [5].

Llamar foo()nuevamente modifica pavlonuevamente:

>>> foo()
[5, 5]

Especificar acuándo llamar foo()asegura pavloque no se toque.

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

Entonces, pavlotodavía está [5, 5].

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

A veces exploto este comportamiento como una alternativa al siguiente patrón:

singleton = None

def use_singleton():
    global singleton

    if singleton is None:
        singleton = _make_singleton()

    return singleton.use_me()

Si singletonsolo lo usa use_singleton, me gusta el siguiente patrón como reemplazo:

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

Lo he usado para crear instancias de clases de clientes que acceden a recursos externos, y también para crear dictados o listas para la memorización.

Como no creo que este patrón sea bien conocido, pongo un breve comentario para evitar futuros malentendidos.

Puede evitar esto reemplazando el objeto (y, por lo tanto, el vínculo con el alcance):

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

Feo, pero funciona.

Puede ser cierto que:

1. Alguien está utilizando todas las funciones de idioma / biblioteca, y
2. Cambiar el comportamiento aquí sería desaconsejado, pero

es completamente consistente mantener ambas características anteriores y aún hacer otro punto:

3. Es una característica confusa y desafortunada en Python.

Las otras respuestas, o al menos algunas de ellas, hacen los puntos 1 y 2 pero no 3, o hacen el punto 3 y minimizan los puntos 1 y 2. Pero las tres son verdaderas.

Puede ser cierto que cambiar caballos en la mitad de la corriente aquí requeriría una rotura significativa, y que podría haber más problemas creados al cambiar Python para manejar intuitivamente el fragmento de apertura de Stefano. Y puede ser cierto que alguien que conociera bien las partes internas de Python podría explicar un campo minado de consecuencias. Sin embargo,

El comportamiento existente no es Pythonic, y Python es exitoso porque muy poco sobre el lenguaje viola el principio de menor asombro en cualquier lugar cercanoesta mal Es un problema real, sea o no conveniente desarraigarlo. Es un defecto de diseño. Si comprende el lenguaje mucho mejor al tratar de rastrear el comportamiento, puedo decir que C ++ hace todo esto y más; aprende mucho navegando, por ejemplo, errores sutiles de puntero. Pero esto no es Pythonic: las personas que se preocupan por Python lo suficiente como para perseverar frente a este comportamiento son personas que se sienten atraídas por el lenguaje porque Python tiene muchas menos sorpresas que otro lenguaje. Dabblers y los curiosos se convierten en Pythonistas cuando se sorprenden del poco tiempo que lleva hacer que algo funcione, no por un diseño fl - quiero decir, un rompecabezas de lógica oculta - que corta en contra de las intuiciones de los programadores que se sienten atraídos por Python porque simplemente funciona .

Esto no es un defecto de diseño . Cualquiera que tropiece con esto está haciendo algo mal.

Hay 3 casos en los que puedo encontrar este problema:

1. Tiene la intención de modificar el argumento como un efecto secundario de la función. En este caso, nunca tiene sentido tener un argumento predeterminado. La única excepción es cuando abusa de la lista de argumentos para tener atributos de función, por ejemplo cache={}, y no se espera que llame a la función con un argumento real.
2. Tiene la intención de dejar el argumento sin modificar, pero accidentalmente lo modificó. Eso es un error, arréglalo.
3. Tiene la intención de modificar el argumento para su uso dentro de la función, pero no esperaba que la modificación fuera visible fuera de la función. En ese caso, debe hacer una copia del argumento, ¡ya sea el predeterminado o no! Python no es un lenguaje de llamada por valor, por lo que no hace la copia por usted, debe ser explícito al respecto.

El ejemplo en la pregunta podría caer en la categoría 1 o 3. Es extraño que ambos modifiquen la lista aprobada y la devuelvan; deberías elegir uno u otro.

¡Este "error" me dio muchas horas extra de trabajo! Pero estoy empezando a ver un uso potencial de él (pero me hubiera gustado que estuviera en el momento de la ejecución, aún)

Te daré lo que veo como un ejemplo útil.

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

imprime lo siguiente

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

Simplemente cambie la función para que sea:

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

Creo que la respuesta a esta pregunta radica en cómo Python pasa los datos al parámetro (pase por valor o por referencia), no en la mutabilidad o cómo Python maneja la declaración "def".

Una breve introduccion. Primero, hay dos tipos de tipos de datos en python, uno es un tipo de datos elemental simple, como los números, y otro tipo de datos son los objetos. En segundo lugar, al pasar datos a parámetros, python pasa el tipo de datos elemental por valor, es decir, hace una copia local del valor a una variable local, pero pasa el objeto por referencia, es decir, apuntadores al objeto.

Admitiendo los dos puntos anteriores, expliquemos qué sucedió con el código de Python. Es solo por pasar por referencia para objetos, pero no tiene nada que ver con mutable / inmutable, o posiblemente el hecho de que la declaración "def" se ejecuta solo una vez cuando se define.

[] es un objeto, por lo que Python pasa la referencia de [] a a, es decir, aes solo un puntero a [] que se encuentra en la memoria como un objeto. Sin embargo, solo hay una copia de [] con muchas referencias. Para el primer foo (), la lista [] se cambia a 1 por el método append. Pero tenga en cuenta que solo hay una copia del objeto de lista y este objeto ahora se convierte en 1 . Cuando se ejecuta el segundo foo (), lo que dice la página web de efbot (los elementos ya no se evalúan) está mal. ase evalúa como el objeto de la lista, aunque ahora el contenido del objeto es 1 . ¡Este es el efecto de pasar por referencia! El resultado de foo (3) se puede derivar fácilmente de la misma manera.

Para validar aún más mi respuesta, echemos un vistazo a dos códigos adicionales.

====== No. 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]

[]es un objeto, también lo es None(el primero es mutable mientras que el segundo es inmutable. Pero la mutabilidad no tiene nada que ver con la pregunta). None está en algún lugar del espacio, pero sabemos que está allí y solo hay una copia de None allí. Por lo tanto, cada vez que se invoca foo, los elementos se evalúan (en oposición a alguna respuesta que solo se evalúa una vez) para ser Ninguno, para ser claros, la referencia (o la dirección) de Ninguno. Luego, en el foo, el elemento se cambia a [], es decir, apunta a otro objeto que tiene una dirección diferente.

====== No. 3 =======

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

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

La invocación de foo (1) hace que los elementos apunten a un objeto de lista [] con una dirección, por ejemplo, 11111111. el contenido de la lista se cambia a 1 en la función foo en la secuela, pero la dirección no se cambia, todavía 11111111 Entonces foo (2, []) viene. Aunque [] en foo (2, []) tiene el mismo contenido que el parámetro predeterminado [] cuando llama a foo (1), ¡su dirección es diferente! Como proporcionamos el parámetro explícitamente, itemsdebe tomar la dirección de este nuevo [], digamos 2222222, y devolverlo después de realizar algún cambio. Ahora se ejecuta foo (3). ya que soloxse proporciona, los elementos deben volver a tomar su valor predeterminado. ¿Cuál es el valor predeterminado? Se establece al definir la función foo: el objeto de lista ubicado en 11111111. Por lo tanto, los elementos se evalúan como la dirección 11111111 que tiene un elemento 1. La lista ubicada en 2222222 también contiene un elemento 2, pero no se señala con ningún elemento más. En consecuencia, un anexo de 3 hará items[1,3].

De las explicaciones anteriores, podemos ver que la página web de efbot recomendada en la respuesta aceptada no dio una respuesta relevante a esta pregunta. Además, creo que un punto en la página web de efbot está mal. Creo que el código con respecto a la interfaz de usuario. El botón es correcto:

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

Cada botón puede contener una función de devolución de llamada distinta que mostrará un valor diferente de i. Puedo proporcionar un ejemplo para mostrar esto:

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

Si ejecutamos x[7](), obtendremos 7 como se esperaba y x[9]()daremos 9, otro valor de i.

TLDR: los valores predeterminados de tiempo de definición son consistentes y estrictamente más expresivos.

La definición de una función afecta a dos ámbitos: el ámbito de definición que contiene la función y el ámbito de ejecución contenido por la función. Si bien está bastante claro cómo se asignan los bloques a los ámbitos, la pregunta es a dónde def <name>(<args=defaults>):pertenece:

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

La def nameparte debe evaluarse en el ámbito de definición: queremos nameestar disponibles allí, después de todo. Evaluar la función solo dentro de sí misma la haría inaccesible.

Como parameteres un nombre constante, podemos "evaluarlo" al mismo tiempo que def name. Esto también tiene la ventaja de que produce la función con una firma conocida como name(parameter=...):, en lugar de una simple name(...):.

Ahora, cuando evaluar default?

La consistencia ya dice "en la definición": todo lo demás también def <name>(<args=defaults>):se evalúa mejor en la definición. Retrasar partes de ella sería la elección asombrosa.

Las dos opciones tampoco son equivalentes: si defaultse evalúa en el momento de la definición, aún puede afectar el tiempo de ejecución. Si defaultse evalúa en tiempo de ejecución, no puede afectar el tiempo de definición. Elegir "en la definición" permite expresar ambos casos, mientras que elegir "en la ejecución" puede expresar solo uno:

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

Cualquier otra respuesta explica por qué este es realmente un comportamiento agradable y deseado, o por qué no debería necesitarlo de todos modos. El mío es para aquellos obstinados que quieren ejercer su derecho a doblegar el lenguaje a su voluntad, y no al revés.

"Arreglaremos" este comportamiento con un decorador que copiará el valor predeterminado en lugar de reutilizar la misma instancia para cada argumento posicional dejado en su valor predeterminado.

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

Ahora redefinimos nuestra función usando este decorador:

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

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

Esto es particularmente bueno para las funciones que toman múltiples argumentos. Comparar:

# 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

con

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

Es importante tener en cuenta que la solución anterior se rompe si intenta utilizar argumentos de palabras clave, de esta manera:

foo(a=[4])

El decorador podría ajustarse para permitir eso, pero lo dejamos como un ejercicio para el lector;)