l = [(lambda: i) for i in range(0, 5)]
[f() for f in l] // [4, 4, 4, 4]

C'est normal ?
Pourquoi y a aucune gestion de portée des variables ?

Je ne suis pas completement sur de savoir de quoi tu parles dans cet exemple. Tu veux dire:

$ cat f.py 
for i in range (0,5):
    pass

print (str(i))
$ python3 f.py 
4

Et la question est "pourquoi est ce que 'i' n'est pas scope dans la boucle for comme ca le serait en c++?"
De ce que je comprends de python, il n'y a que deux scopes:

1. global (ce qui vraiment est package: l'unite d'execution actuelle)
2. local (la fonction courante)

Le 28 juin 2022 à 20:41:25 :
Je ne suis pas completement sur de savoir de quoi tu parles dans cet exemple. Tu veux dire:

$ cat f.py 
for i in range (0,5):
    pass

print (str(i))
$ python3 f.py 
4

Et la question est "pourquoi est ce que 'i' n'est pas scope dans la boucle for comme ca le serait en c++?"
De ce que je comprends de python, il n'y a que deux scopes:

1. global (ce qui vraiment est package: l'unite d'execution actuelle)
2. local (la fonction courante)

ouais mais je pensais qu'une liste en compréhension avait son propre scope étant donné que i n'est pas défini dans le main scope dans mon cas

Le 28 juin 2022 à 20:47:45 :

Le 28 juin 2022 à 20:41:25 :
Je ne suis pas completement sur de savoir de quoi tu parles dans cet exemple. Tu veux dire:

$ cat f.py 
for i in range (0,5):
    pass

print (str(i))
$ python3 f.py 
4

Et la question est "pourquoi est ce que 'i' n'est pas scope dans la boucle for comme ca le serait en c++?"
De ce que je comprends de python, il n'y a que deux scopes:

1. global (ce qui vraiment est package: l'unite d'execution actuelle)
2. local (la fonction courante)

ouais mais je pensais qu'une liste en compréhension avait son propre scope étant donné que i n'est pas défini dans le main scope dans mon cas

Dans une compréhension i reste dans le scope de la compréhension (attention, il y a une exception avec l'opérateur morse qui fait "fuiter" la valeur de i dans le scope englobant).

En python les variables sont des références, même les integers.
A la fin de l'execution de ta comprehension de list, i vaut 4 et toutes les lambda retournent une référence vers i donc retournent 4.

C'est pas spécifique à python, Javascript fait la même chose quand tu fais des trucs de ce genre :

for (var i = 1; i <= 2; i++) {
    setTimeout(function() { alert(i) }, 100);
}

Un workaround serait de "forcer" la copie de i en le faisant passer en paramètre, faire un truc de ce genre:

l = [(lambda i=i: i) for i in range(0, 5)]
[f() for f in l]  # [0, 1, 2, 3, 4]

Plus d'infos ici : https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result

Le 28 juin 2022 à 23:39:21 :
En python les variables sont des références, même les integers.
A la fin de l'execution de ta comprehension de list, i vaut 4 et toutes les lambda retournent une référence vers i donc retournent 4.

C'est pas spécifique à python, Javascript fait la même chose quand tu fais des trucs de ce genre :

for (var i = 1; i <= 2; i++) {
    setTimeout(function() { alert(i) }, 100);
}

Un workaround serait de "forcer" la copie de i en le faisant passer en paramètre, faire un truc de ce genre:

l = [(lambda i=i: i) for i in range(0, 5)]
[f() for f in l]  # [0, 1, 2, 3, 4]

Plus d'infos ici : https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result

Non, en js on utilise le mot clef let, et le problème disparait, var est tombé en désuétude.
Pour ce qui est des références, en haskell toutes les variables sont boxed, pourtant jamais eu l'ombre de ce problème.
l = [\n -> n + i | i <- [1..4]] map (\f -> (f 0)) l -- [1,2,3,4]

On sent que python c'est un langage très archaïque.

On sent que python c'est un langage très archaïque.

Je dis regulierement que Python est un mauvais langage pour concevoir des applications de taille moyenne et large. Python est raisonnable pour gluer des codes ensemble. Mais pour tout ce qui est plus gros que ca, il y a des tonnes de comportement bizarre du langge qui rendent le langage difficilement maintenable.

J'avais un doute mais c'est pareil en Golang donc bon ^^
https://go.dev/play/p/CU4twNUGtgD