Discussion :

[poseidon31]

Bonjour,

Voila j'ai crée un dictionnaire python et mes clés sont des dates auxquelles j'affecte des valeurs.

J'ai besoin de récupérer la toute première clé de mon dictionnaire pour connaitre en fait la date de début.

Je ne suis pas censé connaitre cette date donc j'ai juste besoin d'appeler la première clé de mon dictionnaire.

Est ce que quelqu'un aurait une idée de comment faire çà ?

[josmiley]

Depuis python3 les dictionnaires garde l'ordre de création des clés.

Maintenant, la première date est-elle la plus ancienne ? Si oui, tu peux filtrer sur un min().

[wiztricks]

Salut,

Est ce que quelqu'un aurait une idée de comment faire çà ?

On peut faire çà ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
>>> next(iter(dict.fromkeys((2,3,1))))
2
>>> next(iter(dict.fromkeys((1,2,3))))
1
>>>

Ce qui illustre que l'ordre d'insertion est préservé (pour les versions de Python 3.6+) mais que l'ordre d'insertion est différent de la relation d'ordre sur les clefs...

- W

[poseidon31]

Super, merci beaucoup a tous les deux, j'ai pu résoudre mon problème

[Sve@r]

Bonjour

Depuis python3 les dictionnaires garde l'ordre de création des clés.

Je crois que c'est depuis la version 3.6 plus exactement. Et quoi qu'il en soit, il existe toujours les OrderedDict du module collections.

Maintenant, la première date est-elle la plus ancienne ? Si oui, tu peux filtrer sur un min().

Moi j'aurais plutôt dit "si non". Si la première date est la plus ancienne, alors on peut la récupérer directement, ce sera la plus basse. C'est si ce n'est pas le cas qu'on est obligé de passer par un min(dict.keys())...

[josmiley]

Me suis mal exprimé, je voulais dire que, si le dict n'est pas ordonné et que la date est la plus ancienne, alors on peut min(filtre selon le format de la date). Effectivement, en l'état, Sve@r a raison.

[Invité]

Ou encore :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[key for key in dict.keys()][0]

Y a pas un moyen d'y accéder sans devoir consulter tout le dico ?

[Sve@r]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[key for key in dict.keys()][0]

list(dict.keys())[0]

Y a pas un moyen d'y accéder sans devoir consulter tout le dico ?

next(iter(dict.keys()))

[Invité]

next(iter(dict.keys()))...

Ah ok, je pensais de travers... Autant pour moi !
dict.keys() c'est une classe c'est ça ?
Je trouve le résultat de cette commande bizarre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>>dico = {"ap":8,"ca":0}
>>>dico.keys()
dict_keys(['ap', 'ca'])

Pourquoi ça retourne dict_keys(...) et pas juste ['ap', 'ca'] ? Soyez indulgent je suis con !

Y aurait-il moyen de faire quelque chose avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>>dir(dico.keys())
['__and__', '__class__', '__contains__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__or__', '__rand__', '__reduce__', '__reduce_ex__', '__repr__', '__ror__', '__rsub__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__xor__', 'isdisjoint']

?

[Sve@r]

dict.keys() c'est une classe c'est ça ?

Un dictionnaire est une classe. Et en tant que classe, il possède diverses méthodes dont l'une se nomme "keys()" et retourne une vue sur ses clefs. Mais cette "vue", comme tout en Python, est elle-même aussi un objet qui possède donc ses propres méthodes et attributs.

Je trouve le résultat de cette commande bizarre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>>dico = {"ap":8,"ca":0}
>>>dico.keys()
dict_keys(['ap', 'ca'])

Pourquoi ça retourne dict_keys(...) et pas juste ['ap', 'ca'] ? Soyez indulgent je suis con !

Héhé, ça c'est la nouveauté Python3 et que je trouve tiptop.
Sous Python2, la méthode "keys()" retournait une simple liste (la liste des clefs évidemment et que, semble-t-il, tu t'attendais à avoir aussi ici). Mais quand le dictionnaire évolue, qu'une clef est ajoutée, qu'une autre disparait, la liste retournée est alors devenue obsolète (cette remarque bien évidemment ne s'applique que pour le programmeur qui a récupéré cette liste en écrivant par exemple clefs=dico.keys() et qui ensuite va traiter à part le contenu de "clefs")
Sous Python3, la méthode retourne ce que je nomme une "vue" (en référence aux vues des bdd), c'est à dire un truc focalisé en temps réel sur les clefs du dictionnaire. Si ensuite le dictionnaire change, la vue change en synchronisation.

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
>>> dico = {"ap":8,"ca":0}
>>> k=dico.keys()
>>> print(k)
dict_keys(['ap', 'ca'])
>>> dico["xx"]=123
>>> print(k)
dict_keys(['ap', 'ca', 'xx'])

Sous P2 ce truc existait aussi mais se nommait "viewkeys()" (peut-être aussi pour ça que j'appelle ça une "vue"). Je l'utilisais très souvent et je suis content que la méthode "keys()" de P3 ait choisi ce comportement. D'autant plus que le comportement que tu attends reste possible via un cast => list(dico.keys()) te donnera alors ce ['ap', 'ca'] que tu veux.
Et la même chose existe pour les méthodes "values()" et "items()".

Y aurait-il moyen de faire quelque chose avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>>dir(dico.keys())
['__and__', '__class__', '__contains__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__or__', '__rand__', '__reduce__', '__reduce_ex__', '__repr__', '__ror__', '__rsub__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__xor__', 'isdisjoint']

?

Ben je comprends pas trop ta question. Tu as listé toutes les méthodes de l"objet "dict_keys" (qui, comme je l'ai dit, est lui aussi est un objet). Tu veux faire quelque chose avec quoi ? Les méthodes listées ? Chaque méthode permet de répondre à une problématique qui peut se poser à un programmeur mais ça reste transparent pour le programmeur. Par exemple si tu tapes print(dico.keys()) le bouzin appellera la méthode __str__ et affichera la string qu'elle renvoie. Ce n'est pas à toi d'appeler manuellement dico.keys().__str__ (d'ailleurs toutes les méthodes commençant par deux underscores sont privées et ne sont pas utilisables directement par l'utilisateur).

[Invité]

Ok merci pour toutes ses précisions, pour une fois j'ai compris !

list(dico.keys()) je n'ai même pas pensé à ça ^^

Du coup utiliser l'itérateur est plus rapide (en terme de performance) que la liste, c'est bien ça ?
L'index d'une liste c'est une sorte d'itérateur derrière ou alors ça "pointe" directement vers la "bonne" valeur dans la liste ? Juste pour savoir s'il peut être plus intéressant dans certains cas d'utiliser la liste que l'itérateur pour des gains de performance ("utilisation d'une même liste à plusieurs reprises" versus "parcourir avec l'itérateur à plusieurs reprises").

[Sve@r]

Du coup utiliser l'itérateur est plus rapide (en terme de performance) que la liste, c'est bien ça ?

Il me semble. C'est d'ailleurs pour ça que sous P3, la méthode keys() donne maintenant une vue et plus une liste comme avant.

L'index d'une liste c'est une sorte d'itérateur derrière ou alors ça "pointe" directement vers la "bonne" valeur dans la liste ?

Là je ne sais pas. Mais si je me base sur mon expérience du C, je dirais que c'est un offset. tab[n] correspond à "je me place au début du tableau et je décale de n positions". En tout cas c'est comme ça que ça se passe en C et comme Python a été écrit en C...
Attention toutefois, les opérations basées sur les index (donc les slices aussi) ne sont pas possibles sur un itérateur. Un itérateur soit tu le traites séquentiellement, soit tu passes par une liste (et donc là moi je donne alors la préférence aux tuples puisque les outils de modification ne me sont pas utiles)

Juste pour savoir s'il peut être plus intéressant dans certains cas d'utiliser la liste que l'itérateur pour des gains de performance

Perso je passe toujours par un itérateur. Parce qu'effectivement je pense que c'est plus performant en terme de ram utilisée. Et même pour mes fonctions qui doivent "générer" de l'info j'en fais toujours des générateurs (ie yield) pour que l'info ne soit effectivement générée qu'au moment où j'en ai besoin. Et ce d'autant plus que rien ne m'interdit ensuite de caster ce générateur en liste (ou tuple) si besoin.

("utilisation d'une même liste à plusieurs reprises" versus "parcourir avec l'itérateur à plusieurs reprises").

Si on entre dans des histoires de répétition du travail, là je penche alors pour le parcours de liste (ou de tuple). Puisque le générateur doit "générer" l'info, ça me semble alors plus rapide de parcourir une info stockée en ram qu'une même info recréée à chaque fois que je répète le travail. Mais il y a aussi la question du "le dico originel sera-t-il modifié entre deux parcours ?". Hé oui, en offrant la possibilité de renvoyer un ensemble de trucs, on ne pensait pas à ces problématiques qui sont "est-ce que quand j'en serai à traiter le dernier truc renvoyé, ce truc sera-t-il encore d'actualité ?". Bref quand on arrive à ces problématiques, je pense que ça ne peut se gérer qu'au cas par cas.

[Invité]

Merci pour toutes ses précisions !
Il faudrait qu'un jour je m'intéresse au générateur et à yield.

[Sve@r]

Il faudrait qu'un jour je m'intéresse au générateur et à yield.

Pas compliqué
Tu prends une fonction qui renvoie d'un coup un itérable => def fct(): return (1, 2, 3, 4, 5). Tu peux alors l'utiliser de cette façon: for i in fct(): print(i).
Là, tu remarques alors que tu as retourné un tuple (ça mange de la ram) pour utiliser ses éléments un à un. Le tuple était-il vraiment utile ?

Tu remplaces alors le return de la fonction par un yield

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
def fct():
	yield 1
	yield 2
	yield 3
	yield 4
	yield 5

Ca ne change absolument rien à ta façon de l'utiliser => for i in fct(): print(i). Simplement chaque valeur est "générée" au moment où tu en as besoin => tu as créé un générateur.

Alors ok, tu peux dire "je m'en fouts j'ai de la ram, je peux garder le tuple". Ok. Mais que se passe-t-il avec ce code

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
from datetime import *
import time
 
def fct(x):
	ret=[]
	for i in range(x):
		ret.append(datetime.today().strftime("%H:%M:%S"))
	return ret
 
for (i, f) in enumerate(fct(5), 1):
	print(i, f)
	time.sleep(5)

Ton code met 25 secondes pour se terminer mais te donne 5 fois la même heure, celle qui a été créée quand la fonction a été appelée au début. C'est ce dont je parlais quand je parlais d'obsolescence de l'information.

Alors qu'avec un générateur...

Code python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
from datetime import *
import time
 
def fct(x):
	for i in range(x):
		yield datetime.today().strftime("%H:%M:%S")
 
for (i, g) in enumerate(fct(5), 1):
	print(i, g)
	time.sleep(5)

L'information que tu obtiens à la 25° seconde est bien l'heure du moment. Tu as un truc bien plus proche du temps réel (si par exemple tu gères des stockes de bouffe dans un entrepot, c'est mieux d'avoir le nombre de boites au moment où tu en as besoin que le nombre de boites qu'il y avait avant l'ouverture).

Perso je n'utilise maintenant que des générateurs parce que ça fait "pareil que sans" mais mieux. Surtout que si je veux, je peux quand-même revenir au comportement originel => data=tuple(fct(5)).

[Invité]

Ok !
Moi j'aurais eu tendance à utiliser threading pour ton exemple, je pense.