récupérer la 1ere clé d'un dictionnaire python

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 çà ?

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

Salut,

Citation:

---

Envoyé par poseidon31

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

---

On peut faire çà ainsi:

Code:

---

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

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

Bonjour

Citation:

---

Envoyé par josmiley

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.

Citation:

---

Envoyé par josmiley

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

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.

Ou encore :

Code:

---

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

---

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

Citation:

---

Envoyé par LeNarvalo

Code:

---

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

---

---

list(dict.keys())[0] :mrgreen:

Citation:

---

Envoyé par LeNarvalo

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

---

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

Citation:

---

Envoyé par Sve@r

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:

---

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 ! :mrgreen:

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

Code:

---

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

---

?

Citation:

---

Envoyé par LeNarvalo

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.

Citation:

---

Envoyé par LeNarvalo

Je trouve le résultat de cette commande bizarre :

Code:

---

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 ! :mrgreen:

---

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:

---

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

Citation:

---

Envoyé par LeNarvalo

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

Code:

---

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

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

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

Citation:

---

Envoyé par LeNarvalo

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.

Citation:

---

Envoyé par LeNarvalo

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)

Citation:

---

Envoyé par LeNarvalo

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.

Citation:

---

Envoyé par LeNarvalo

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

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

Citation:

---

Envoyé par LeNarvalo

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:

---

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:

---

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:

---

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

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