Python liste et chaine de caractères

[invitec2d1a74e]

Bonjour,

Je suis en train de faire un programme pour chiffrer des fichiers, il marche quand je n'en ai que 1 a chiffrer et que j'entre son nom avec un input mais lorsque je dois en chiffrer plusieurs dans un dossier, j'ai créer une liste contenant tout les noms des fichiers pour pouvoir appeler ma fonction de chiffrage autant de fois qu'il y a de fichiers cependant le programme ne reconnais pas le nom des fichiers venant de la liste. Merci d'avance pour votre aide

Erreur : FileNotFoundError: [Errno 2] No such file or directory: 'logins.txt' #Je pense que c'est a cause des guillemets

mon code :

print("Entrez le nom du dossier : ",end="")
            file_dir = input()
            if os.path.exists(file_dir) == True :
                list = os.listdir(file_dir)
                print("Voici tout vos fichiers à chiffrer : ",list)
                print("Entrez le mot de passe : ",end="")
                password = input()
                n = len(list)
                print(list[0])
                print(list[0],chiffrement_AES(password, "1234567890ABCDEF".encode(), list[0]))    #je test d'abord uniquement pour le premier fichier 
                #for i in range(n):                     
                    #print("Le fichier ",list[i]," a été chiffré en : ",chiffrement_AES(password, "1234567890ABCDEF".encode(), list[i]))  # pour tout les fichiers

l'affichage :
Entrez le nom du dossier : fichier
Voici tout vos fichiers à chiffrer : ['logins.txt', 'privateKey.pem']
Entrez le mot de passe : password
logins.txt # le nom du premier fichier pour verifier
-----

[micapivi]

Bonjour

…Erreur : FileNotFoundError: [Errno 2] No such file or directory: 'logins.txt' #Je pense que c'est a cause des guillemets…

Ou alors c'est qu'il lui faut le chemin absolu du fichier plutôt que seulement le nom du fichier

[invitec2d1a74e]

ah oui complètement, ca doit être ca je suis bête de pas y avoir pensé merci et bonne soirée

[polo974]

Pour info, tu peux avantageusement faire:

for fich in listfich:
    ...

Plutôt que de prendre la longueur de la liste pour faire une boucle...

[A voir en vidéo sur Futura]

[Merlin95]

Ce n'est pas que du sucre syntaxique ?

[pm42]

Ce n'est pas que du sucre syntaxique ?

Non c’est intrinsèquement plus propre notamment parce qu’en général on passe par un iterateur.
Si il y a une modification concurrente de la liste, l’iterateur peut gérer alors que de passer par un index va planter.

On unifie aussi le parcours de toutes les collections (ou plus génèralement des iterables) comme ça : si on décide de passer un Set, le code continuera à marcher. Celui avec les index plantera.

[Merlin95]

Du coup c'est le contraire : les perfs doivent être moindres si la collection gère les concurrence d'accés, non ?
Mais ici la liste est dans une méthode donc je vois pas pourquoi elle serait partagée à d'autres endroits. pour la rapidité du coup vaut mieux utiliser un moyen de parcours de la liste qui ne gère pas la sychronicité. C'est en tout cas ce que j'ai appris. Après c'est vrai que la syntaxe est plus sympa.

[pm42]

C’était juste un exemple : la plupart des collections ne gèrent pas ce genre d’accès concurrent mais cette syntaxe le rend possible naturellement.

Quand aux perfs, c’est un vaste sujet notamment en python qui est lent.

[Merlin95]

Ok j'ai compris pour les perfs facile : une boucle de 1000000 qui parcours la liste et on compare les temps d'exécution.

[Merlin95]

Non c’est intrinsèquement plus propre notamment parce qu’en général on passe par un iterateur.
Si il y a une modification concurrente de la liste, l’iterateur peut gérer alors que de passer par un index va planter.

On unifie aussi le parcours de toutes les collections (ou plus génèralement des iterables) comme ça : si on décide de passer un Set, le code continuera à marcher. Celui avec les index plantera.

C'est une philosophie que je n'aime pas je préfère utilisé le plus performant au plus uniforme et laisser la responsabilité au développeur de savoir ce qu'il fait. Les relectures de code permettent en plus facilement de corriger ces aspects en tout cas dans le cadre d'un moyen projet. Plus grand je penserais différemment.

[polo974]

Tu dis préférer le plus performant, mais avoue au message précédent ne pas savoir lequel est le plus performant...

Quand je suis passé du C au python, j'utilisais aussi les indices, mais mon vieux code python me pique les yeux maintenant quand je le relis (je continue aussi à coder en C et C++).

[pm42]

Et sur un vrai code, le plus uniforme sera le plus performant à terme. D’autant que ce genre de micro-optimisation, choix de boucle vs la vraie optimisation, algorithmique, n’a pas d’effet positif. Cela a été montré il y a déjà longtemps par une étude de Knuth notamment.

[Merlin95]

Tu dis préférer le plus performant, mais avoue au message précédent ne pas savoir lequel est le plus performant...

Oui et ? Je pense que c'est la version qui ne gère pas la concurrence qui est le moins rapide, c'est par exemple le cas en Java je ne vois pas pourquoi il en serait autrement en python. Seul un vrai test permet de savoir quantativement.

[pm42]

Encore une fois c’était un exemple et qui était lié à la collection utilisée, pas au type de boucle for.

[Merlin95]

Ok je n'ai pas compris ça alors :

Non c’est intrinsèquement plus propre notamment parce qu’en général on passe par un iterateur.

[pm42]

Ok je n'ai pas compris ça alors :

Un iterateur peut être ou ne pas être résistant aux modifications concurrentes.
La plupart du temps il ne l’est pas mais parfois il est pratique voire nécessaire qu’il le soit.

Supposons que j’ai une liste donc une collection indexée. Je peux la passer a une autre collection qui va servir de façade et être capable de me fournir un iterateur dessus qui gère proprement les modifications concurrentes.

Cette nouvelle liste n’est pas indexée puisque des éléments peuvent être ajoutés ou supprimés pendant qu’on l’utilise.
Mais elle est iterable donc on peut utiliser la syntaxe

for l in list

dessus mais pas la syntaxe avec un

range

Si on utilise dès le départ les syntaxes les plus génériques, «*for l in list*», map/reduce, les comprehensions, on peut plus facilement modifier les structures pour les rendres plus adaptées au fur et à mesure de l’évolution du programme, parallèliser, etc.

Au final, on aura plus de flexibilité et de performance qu’en cherchant des petites optimisations dès le début.

[Merlin95]

Qu'est-ce ne ferait pas pour éviter un rechercher/remplacer m'enfin j'ai compris avec la syntaxe "in" on peut gérer à moindre frais tout l'aspect concurrentiel. En pratique on corrigé surtout quand on a une exception du à une concurrence d'accés.

Ou alors on implémente son propre mécanisme de concurrence d'accés personnalisé. Mais la théorie c'est très important.

[pm42]

Je pense que tu n’as pas compris et que réaction n’est pas la bonne. La remarque sur le chercher/remplacer n’est absolument pas pertinente quand il s’agit d’écrire du code de façon industrielle. Celle sur la théorie me semble limite.
J’arrête là vu le peu d’intérêt de continuer à expliquer ce qui est pourtant la norme de programmation dans tous les langages plus récents que Fortran.

[Merlin95]

Sur la théorie c'était pas ironique.