voilà, j'ai un code python qui est censé retourner les chiffres pairs et impairs mais il marche pas

voici la bete :

merci, ++

Je crois que tu n'as pas compris l'utilisation des listes, elle possede des methodes pour se simplifier la vie, il n'est pas necessaire de rechercher la taille de la liste puis de faire une boucle while, economise tes variables. Il est plus simple de faire:

ou

elpacificator -> j'ai compris que la moitié ^^ ( même pas )  
 
comme j'ai commencé hier soir, ben je sais pas trop comment marche ton code :-°
 
merci, ++

ca ca devrait aller
Un des mecanismes puissant de python: la list comprehension, elle permet de generer une liste à partir d'une autre liste en appliquant un traitement sur chaque element et en filtrant certain d'entre eux.
 
Je ne saurais trop te conseiller de lire un tutoriel sur python, ca ne sert à rien de poser des questions si tu n'as pas le minimum pour comprendre les reponses....

la version avec les list comprension  

suite = [21, 45, 68, 91, 165, 16, 12, 2, 5]
pair = [n for n in suite if n%2 == 0]
impair = [n for n in suite if n not in pair]

python c'est du bonheur en 3 lignes
 
edit: grillé par le pacificateur

Harkonnen -> rien compris xD
Elpacificator -> ca va mieux, mais j'ai pas encore vu les boucles for, tu pourrais me donner un peu d'explications ?

thx, ++

splus la classe

 
comparer une expression avec 0, c'est bof la classe AMHA.    

suite = [21, 45, 68, 91, 165, 16, 12, 2, 5]
pair, impair = [n for n in suite if n%2 == 0],[n for n in suite if n not in pair]

champion du monde
 
edit: ah ben non, ça marche pas ! normal, pair n'existe pas au moment de la création de impair

suite = [21, 45, 68, 91, 165, 16, 12, 2, 5]
def partition(fun, arr):
    return filter(fun, arr), filter(lambda v: not(fun(v)), arr)
 
impair, pair = partition(lambda v: v%2, suite)
# ou bien
impair, pair = partition(lambda v: v&1, suite)

Higher Order Functions FTW

À noter par contre que le manque d'opérateur de composition de fonction en Python force à créer une lambda intermédiaire un peu crade à partition, en Haskell c'est beaucoup plus clean puisque partition est défini comme:

À noter également que ma solution est super générique puisqu'elle permet par exemple de partitionner des mots selon que leur longueur est paire ou impaire, ou des objets selon leur taille en mémoire, ou n'importe quoi d'autre, juste en changeant la lambda

En plus ça permet d'utiliser facilement les prédicats Python existants

En version générique, je préfère

def partition(fun, arr):
    return reduce(lambda b, n:b[bool(fun(n))].append(n) or b, arr, ([],[]))

ça évite la double évaluation de fun et ne parcours arr qu'une seule fois.

Ouais mais c'est franchement imbitable.

Et l'utilisation de la sortie de `bool` comme un entier est franchement discutable...

La classe bool étant une sous classe de int en python, c'est pas franchement laid je trouve

Ben si, sémantiquement c'est très moche, un booléen s't'un booléen pas un entier, quelle que soit l'implémentation

Et ça ne rend pas ton code plus compréhensible

Non parce que je rappelle quand même:

Et là paf, steak haché

C'est pas une histoire d'implémentation, un booléen est un entier et python le dit c'est tout donc en python c'est vrai
'fin si ça te chagrine c'est de toute façon facile à 'corriger' (y'a plein de manières de le faire d'ailleurs) sans changer le principe du remplissage de listes avec reduce.

La lisibilité et l'esthétisme sont relativement subjectifs et ne se compte pas nécessairement en quantité de ponctuation
Conceptuellement mon code reflète mieux la logique d'une partition, je fait 2 listes vides et j'envoie chaque élément de la liste soit à 'droite', soit à 'gauche'.
Le tient ne met pas aussi bien (à mon goût du moins, là aussi c'est subjectif) en évidence le contrat selon lequel les 2 listes retournées contiennent les mêmes éléments que la liste en entrée.

D'ailleurs ton truc se comportera d'une manière assez inattendue avec la fonction suivante :

def fun(val):
   return random.choice((True,False))

(Oui la fonction n'est pas pure, etc... mais c'est une manière possible de décider d'une partition, voire un implémentation relativement logique pour partitionner aléatoirement un ensemble)

Laisse, c'est du masklinn coding, une façon de codage que seul masklinn comprend

Nan fondamentalement il a parfaitement raison sur le random(), c'est juste que c'est complètement con comme idée, et que ma structure présuppose que le prédicat est idempotent (ou référentiellement transparent, comme tu préfères)

je ne comprends absolument rien a tous vos termes techniques, mais ça m'interesse grandement^^

Je ne connaissais pas la methode de 0x90, jadore python.

Desolé pour les pythonistes de la preimère heure, mais va bientôt falloir se passer des lambda, des reduce et des map dans un proche avenir.
Même GVR trouve qu'il faut les supprimer au profit des list comprehension qui sont plus lisibles.
 
Ca va être dur pour certain, je pense ...

Désolé pour toi, mais il va bientôt falloir que tu te mettes à jour: les lambdas ne bougent pas (*), map ne bouge pas non plus, idem pour filter (les deux derniers pouvant par contre être déplacés dans un namespace à part plutôt que d'être dans le global, je ne crois pas qu'une décision finale ait été faite sur le sujet), seul reduce saute.

*: Et le seule moyen pour qu'elles soient retirées auraient été une meilleure syntaxe pour les fonctions anonymes, ce à quoi la communauté python n'est pas parvenue, en tout cas elle n'est pas parvenue à quelque chose plaisant à GvR

tiens, petite question au passage : c'est quoi la différence entre un Set et une list ? dans quel cas utiliser l'un ou l'autre ?

Le set est une collection non-ordonnée de valeurs non redondantes:

• Un set n'a pas d'ordre, alors qu'une list a un ordre (donc on ne peut pas trier un set, ...)
• Il n'est pas possible d'avoir deux fois "le même" objet dans un set (donc deux objets strictement égaux via __eq__), ça ne pose aucun problème dans une list (e.g. set([1,1,1]) est impossible alors que [1,1,1] n'est pas un problème)
• Les sets ont tout un jeu de méthodes pour la gestion d'intersections, différences, unions de sets que les listes n'ont pas
• Les sets sont également beaucoup plus rapide pour des tests d'appartenance (foo in my_set vs foo in my_list)

En fait, tu peux considérer qu'un set est un dictionary dont tu n'utilises que les clés (c'est comme ça qu'il était implémenté dans Python 2.3 si je me souviens bien)

Pour leurs utilisations, les sets sont plutôt à utiliser pour créer des ensembles (n'ayant pas d'ordre, pas de redondances, et très utilisés pour le test de contenance). Pour plus d'infos, "3.7 Set Types" dans la doc Python

 
Je viens de tomber sur ce thread, et en tant que nouveau pythoniste venant de languages plus bas niveau (C, java...) je suis étonné par les compréhensions de liste et notamment celle de impair, en particulier j'ai l'impression que pour tout element de suite, on fait une boucle sur TOUT les elements de pairs pour savoir si il est dedans et si il ne l'est pas on le met dans impair.
 
Je suppose que python implémente ca d'une meilleure manière mais ca suppose qu'il ait compris que la liste soit ordonnées, non redondante, etc... Vu que tout le monde adore les compréhensions de liste je suppose que c'est le cas et que python est TRES intelligent mais si qqu'un pouvait detailler un peu le fonctionnement d'une compréhension de liste j'aimerais bien ^^ et pas juste de savoir que ca marche de manière miraculeuse (oui oui, je sais les programmeurs venant du C sont chiant a tout vouloir comprendre )

1) C'est aussi ce qui m'a sauté aux yeux à la lecture. Je suppose que c'est fait pour des raisons pédagogiques, et qu'une implémentation efficace serait

 
2) une compréhension de liste, c'est un nom bien pompeux pour ce qui n'est qu'un grep de liste (ou une  combinaison d'un grep et d'un map)
Le code équivalent en perl aurait été

 
Bon sinon, j'ai un one liner perl pour construire et remplir les listes, je laisse le soin aux spécialistes de python (ce n'est pas mon cas) de le transposer en ce langage.

L'idée sous-jacente est que si j'ai une liste @suite, et une fonction f des valeurs de la liste dans les nombres naturels, on peut partitionner la liste en fonction des valeurs de f en faisant map {push $partition[f($_)], $_} @suite;  
Plus un peu de cuisine dans ce cas précis, pour aller sur @pair et @impair plutôt que sur $partition[0] et $partition[1].
 
A+,

Correct. C'est pédagogiquement simple et vu la longueur des listes ça va pas spécialement être un problème (des versions théoriquement plus efficaces en O(n) sont données derrière dans le thread)

pas du tout.

Une listcomp desugar trivialement:

[op(a, b) for a in aa for b in bb if cond1(a) if cond2(b)]

devient

out = []
for a in aa:
    for b in bb:
        if cond1(a):
            if cond2(b):
                out.append(op(a, b))

C'est bien devrais en informer Rod Burstall et John Darlington, ces salauds ayant introduit le concept dans NPL en 1977, inspirés par des enflures de mathématiciens

Accessoirement le rôle premier des listcomps c'est map, pas filter.

@suite = (21, 45, 68, 91, 165, 16, 12, 2, 5);
# construit et remplit les listes @pair et @impair
map {push @{('pair', 'impair')[$_&1]}, $_} @suite;

T'as vu que t'avais 7 ans de retard? http://forum.hardware.fr/hfr/Progr [...] m#t1521927

La def de wikipedia: the list comprehension, which combines map and filter operations over one or more lists.
et aussi:  filter is a higher-order function that processes a data structure (typically a list) in some order to produce a new data structure containing exactly those elements of the original data structure for which a given predicate returns the boolean value true.
Donc filter, c'est ce qu'on nomme grep en perl, et map est map en perl, bref, on retombe exactement sur ce que j'avais dit:  

 
 
Et comme je suis moi même une de ces enflures de mathématicien, je pense toujours que c'est un nom pompeux, la transposition de la dénomination mathématique, liste définie par compréhension aurait été beaucoup moins jargonnesque que compréhension de liste (ça s'apprenait au collège de mon temps, les deux types de définition d'un ensemble, l'extension et la compréhension).
 
A+,

J'dis juste que t'es dans le mauvais sens, dans une listcomp la collection est toujours présente, le filtrage pas

Et accessoirement les listcomps font aussi une itération multiple pas trivialement expressible via map. Après on peut dire que c'est une vulgaire composition de réductions, mais ça se finit en turing tarpit

OK Plains toi à yertle75 que sa traduction te déplait, il n'y a pas de différence en VO

> J'dis juste que t'es dans le mauvais sens, dans une listcomp la collection est toujours présente, le filtrage pas
 
Dans la jargonnique python sans doute, dans le concept mathématique, non (cf un sous ensemble d'un ensemble défini en compréhension par filtrage sur la valeur d'un prédicat booléen).
 
> Plains toi à yertle75 que sa traduction te déplait
Elle est manifestement pas de lui, on la voit pas mal sur internet, alors que l'autre traduction, liste en compréhension, serait bien plus appropriée.
 
A+,