Cherche équivalent à print(*list) pour sys.stdout.write()

Bonjour,

Sur ce code :

Code:

---

1 2	list =[1,2,3,4,5] print(*list)

---

On affiche rapidement les éléments de list :

Code:

---

1 2 3 4 5

---

Je cherche une astuce aussi simple et rapide en utilisant sys.stdout.write() pour afficher les éléments de list.

Sur ce code :

Code:

---

1 2 3

import sys list =[1,2,3,4,5] sys.stdout.write(str(list) +'\n')

---

J'affiche la liste :

Code:

---

[1, 2, 3, 4, 5]

---

Comme avec :

Code:

---

print(list)

---

J'ai bien essayé de mettre des "*" dans tous les sens mais bien évidemment ça ne marche pas.
J'ai fini par convertir la liste d'integer en liste de string :

Code:

---

1 2 3 4

import sys list =['1','2','3','4','5'] list =' '.join(list) sys.stdout.write(str(list) +'\n')

---

Ça marche, mais c'est franchement nul... y-a pas autre chose?

Salut,

Citation:

---

Envoyé par MissLoop

Je cherche une astuce aussi simple et rapide en utilisant sys.stdout.write() pour afficher les éléments de list.

---

Code:

---

print(*list, file=sys.stdout)

---

- W

Merci beaucoup.

En fait les temps d'exécution sont plutôt équivalents entre :

Code:

---

1 2 3

print(*list) # & print(*list, file=sys.stdout)

---

La vraie différence doit sûrement être plus significative sur des objets plus grands.

Par contre si je reprends ma méthode galère, le temps d'exécution est super et même inférieur à l'affichage de la liste brute avec print().
Seulement j'affiche des string.
Donc bon an mal an en ajoutant l'exécution du retour à une liste d'integer, le temps risque de peut être s'alourdir selon la taille de l'objet?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

list3 =list(range(101))   list4 =list(range(101)) for i in range(len(list4)): list4[i] =str(i) list4 =' '.join(list4)   t1 =time.clock() print(*list3)############################## t2 =time.clock() sys.stdout.write('PERFORM = %f\n' %(t2-t1) +'\n')   t1 =time.clock() print(*list3, file =sys.stdout)############ t2 =time.clock() sys.stdout.write('PERFORM = %f\n' %(t2-t1) +'\n')   t1 =time.clock() print(list3)############################### t2 =time.clock() sys.stdout.write('PERFORM = %f\n' %(t2-t1) +'\n')   t1 =time.clock() sys.stdout.write(str(list4) +'\n')######## t2 =time.clock() sys.stdout.write('PERFORM = %f\n' %(t2-t1) +'\n')

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 8 3 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 PERFORM = 0.000050   0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 8 3 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 PERFORM = 0.000043   [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 2 2, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 4 2, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 6 2, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 8 2, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100] PERFORM = 0.000010   0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 8 3 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 PERFORM = 0.000002

---

Salut,

Citation:

---

Envoyé par MissLoop

Donc bon an mal an en ajoutant l'exécution du retour à une liste d'integer, le temps risque de peut être s'alourdir selon la taille de l'objet?

---

Construire la chaîne de caractères à partir de la liste d'entiers est boulot que "print" vous évite de coder si vous passez par .write.
Si vous comparer les 2 opérations, il faut comparer à "travail équivalent".

Normalement vous devriez obtenir des temps comparables.

Après, au plus la liste d'entier à convertir sera "grande", au plus çà prendra du temps... mais si vous affichez quelque chose, c'est pour le regarder et le temps que vous allez passer à lire les centaines de nombres sera tellement grand que vous ne le ferez pas (et plus la peine de les afficher).

- W

Entièrement d'accord.
La pertinence de l'affichage est à prendre en compte et si affichage il doit y avoir, alors je peux toujours construire une fonction qui va bien pour conjuguer typage et performance.

Encore merci.

j'ai l'impressions que vous chercher à résoudre un problème que n'existe pas, non pas que l'optimisation n'est pas important mais que si vous trouvez que print n'est pas assez performant alors autant réécrire toutes les roues de Python et Python lui même, ou mieux utiliser un langage plus performant.

Bonsoir,

pour avoir déjà remplacé stdout/stderr pour réaliser un logger (avant de connaître la librairie logging)

print va appeler stdout.write pour chaque élément + sep + end

pour rappel sous python 3 :

Code:

---

print(*objects, sep=' ', end='\n', file=sys.stdout, flush=False)

---

Cela veut dire que si on imprime l'objet list print va simplement appeler str() alors que si on l'unpack avec * le message va être décomposé en plus de rajouter le séparateur.
Et si votre objectif est d'optimiser le print autant passer par "".join() plutôt que de laisser gérer print.

Voici un exemple de parsing stdout/stderr pour démontrer la situation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

import sys   class Logger(object): # { i = 0 def write(self, message): # { self.i += 1 self.terminal.write("{:3d}: {!r}\n".format(self.i, message)) # } write def flush(self): # { self.terminal.flush() # } flush # } Logger   class Logger_stderr(Logger): # { def __init__(self): # { self.terminal = sys.stderr # } __init__ def __del__(self): # { if hasattr(sys, 'stderr'): sys.stderr = self.terminal # } __del__ # } Logger_stderr   class Logger_stdout(Logger): # {   def __init__(self): # { self.terminal = sys.stdout # } __init__ def __del__(self): # { if hasattr(sys, 'stdout'): sys.stdout = self.terminal # } __del__ # } Logger_stdout   if __name__ == '__main__': # { my_list =[1, 2, 3, 4, 5] print(my_list) print(*my_list) try: sys.stdout = Logger_stdout() sys.stderr = Logger_stderr() print(my_list) print(*my_list) finally: sys.stdout.__del__() # Recharge stdout original sys.stderr.__del__() # Recharge stderr original print("fin") # } __main__

---

Le résultat :

Citation:

---

[1, 2, 3, 4, 5]

1 2 3 4 5

1: '[1, 2, 3, 4, 5]'
2: '\n'


3: '1'
4: ' '
5: '2'
6: ' '
7: '3'
8: ' '
9: '4'
10: ' '
11: '5'
12: '\n'

fin

---

Salut,

Citation:

---

Envoyé par YCL-1

Cela veut dire que si on imprime l'objet list print va simplement appeler str() alors que si on l'unpack avec * le message va être décomposé en plus de rajouter le séparateur.

Et si votre objectif est d'optimiser le print autant passer par "".join() plutôt que de laisser gérer print.

---

Sur le papier, çà fait du sens... mais si on teste, il n'y a pas de grandes différences: si faire le .join et un .write, c'est exécuter plus d'instructions Python (lentes), si on passe le tout à "print", çà vole en C.

- W

Citation:

---

Envoyé par flapili

j'ai l'impressions que vous chercher à résoudre un problème que n'existe pas, non pas que l'optimisation n'est pas important mais que si vous trouvez que print n'est pas assez performant alors autant réécrire toutes les roues de Python et Python lui même, ou mieux utiliser un langage plus performant.

---

Tout en restant une farouche opposante à la sodomies des mouches, il me semble que chercher à résoudre un problème qui n'existe pas, c'est apporter à l'utopie la suspicion d'une réalité, l'hypothèse d'un éventuel possible (des postulats ont été construits pour moins que ça). Au delà de toutes impressions il n'en reste pas moins que mon temps m'appartient.
Quant à réécrire Python, j'avoue ne pas bien comprendre pourquoi... Mais en ce qui concerne l'utilisation d'un langage plus performant, peut être pouvez-vous m'éclairer? J'ai visionner récemment une vidéo d'un cours de Gérard BERRY captée au CIRM sur "L'importance des langages en informatique"

https://www.youtube.com/watch?v=YnP9zozpDYg
Il fait dans ce cours une comparaison entre un code Cpp et Python (44:33 à 48:20), pour conclure que "...côté sécurité de programmation...c'est le plus bas de gamme qu'on ai fabriqué depuis l'Assembleur..." en parlant de Python.
Ce qui m'échappe dans cette démonstration : En quoi la faute d'orthographe fait marcher les programmes? En quoi p.z dans le code Cpp serait juste un bug?

Citation:

---

Envoyé par YCL-1

Et si votre objectif est d'optimiser le print autant passer par "".join() plutôt que de laisser gérer print.

Voici un exemple de parsing stdout/stderr pour démontrer la situation :

---

En parlant du "".join(), mon code:

Code:

---

1 2 3 4

list4 =list(range(101)) for i in range(len(list4)): list4[i] =str(i) list4 =' '.join(list4)

---

est franchement nul, je construit une liste d'index en string... au lieu de reproduire une liste identique en string:

Code:

---

list4[i] =str(list4[i])

---

Ceci dit merci pour la démo :ccool:
J'ai hâte de faire la comparaison avec la librairie logging ;)

Citation:

---

Envoyé par MissLoop

Tout en restant une farouche opposante à la sodomies des mouches, il me semble que chercher à résoudre un problème qui n'existe pas, c'est apporter à l'utopie la suspicion d'une réalité, l'hypothèse d'un éventuel possible (des postulats ont été construits pour moins que ça). Au delà de toutes impressions il n'en reste pas moins que mon temps m'appartient.

Quant à réécrire Python, j'avoue ne pas bien comprendre pourquoi... Mais en ce qui concerne l'utilisation d'un langage plus performant, peut être pouvez-vous m'éclairer? J'ai visionner récemment une vidéo d'un cours de Gérard BERRY captée au CIRM sur "L'importance des langages en informatique"

---

En faite ce que je voulais dire par là c'est qu'il n'y a pas de raison d'essayer de réécrire print dans le sens où cette fonction est tout à fait optimisé pour ce qu'on lui demande de faire (sérialisé un object avec ses méthodes __str_ / __repr__) pour y écrire dans un flux.
print est avant tout utilisé à des fin des debug/test et la différence de performance entre write et print est d'un coté relativement faible et ne répondent pas aux même besoin.
En pratique on utilise différent outils comme les logger si l'on doit garder des traces / log les erreur post-mortem, en Python c'est le module logging qui est le plus utilisé car dans le std, sinon il y a aussi celui de matrix twisted mais qui est compliqué à utiliser.

Citation:

---

https://www.youtube.com/watch?v=YnP9zozpDYg
Il fait dans ce cours une comparaison entre un code Cpp et Python (44:33 à 48:20), pour conclure que "...côté sécurité de programmation...c'est le plus bas de gamme qu'on ai fabriqué depuis l'Assembleur..." en parlant de Python.
Ce qui m'échappe dans cette démonstration : En quoi la faute d'orthographe fait marcher les programmes? En quoi p.z dans le code Cpp serait juste un bug?

---

Je n'ai visionné qu'une partie de la vidéo et je trouve que dans son discours il y à un nombre incroyable de connerie ... c'est bien pour ça qu'on met en place des tests unitaires dans les bibliothèques sérieuses

il mélange plein de chose, est incohérent avec lui même et utilise des arguments de l'homme de paille (on peux rajouter un attribue à la volé sur un object donc ça veux dire que la faute de frappe fait marcher les programmes)
et dit des phrases très approximatives "y'a des gens qui m'ont dit oui mais on peut rajouter dans Python un machin qui va ajouter un champ à une classe, je regarde dans la doc python c'est marqué, et qu'est ce qu'il y a marqué à coté: pour améliorer l'efficacité
Pièce jointe 565896
bon bah il ne donne pas le source ni le mécanisme derrière donc bon, et je ne trouve pas, peux être parlait il de setattr ? on ne saura jamais.
ps: il pourrait au moins utiliser le bon vocabulaire .... employer champ à la place d'attribue montre bien qu'il n'a jamais cherché à comprendre


puis rajoute "on se fou de la correction", je ne vais même pas commenter la conclusion, il change assez souvent de sujet en milieu de phrase et hop ni vu ni connu il exploite un biais cognitif, après il crache sur une partie des développeurs web puis dit "après c'est normal que les téléphone se plantent"

bon je vais pas faire un debunk d'une vidéo qui à 3000 vues d'autant plus que contrairement à lui je ne sais pas tout :aie: et puis bon ... j'ai pas envie de regarder 2h d'un gars qui passe du sujet des bugs à la sécurité dans les avions pour nous perdre, à l'oral c'est facile de touiller le cerveaux des gens.

Je vous conseil de ne pas prendre ce qu'il dit à la lettre

ps: oh putin c'est définitivement un charlatan ... dire que Einstein dit n'importe quoi pour réconforter son argumentaire ... une honte
ps2: bon bah l’électricité va à la vitesse de la lumière vers 53mn ...
ps3: je ne trouve rien concernant avec les mots clef "programmation parallèle vibration" donc bon .... on va dire que c'est très pointu et que je ne sais pas utiliser de moteur de recherche


quand on voit le public composé à grande majorité de calvitie j'ai juste l'impression qu'il veux embobiner des petits vieux ... quand je vois certaines personnes assistant à ça et qui rigolent / le sourire au coins de la bouche ça je me dit qu'ils se moquent surement de ce charlatan

Bonjour

Citation:

---

Envoyé par MissLoop

En parlant du "".join(), mon code:

Code:

---

1 2 3 4

list4 =list(range(101)) for i in range(len(list4)): list4[i] =str(i) list4 =' '.join(list4)

---

est franchement nul, je construit une liste d'index en string... au lieu de reproduire une liste identique en string:

Code:

---

list4[i] =str(list4[i])

---

---

Si list4[i] contient i, alors vaut mieux écrire list4[i]=str(i). On évite au-moins une indirection.
Mais plus simplement autant faire directement list4=' '.join(str(i) for i in range(101)).

Salut,

Citation:

---

Envoyé par MissLoop

Ce qui m'échappe dans cette démonstration : En quoi la faute d'orthographe fait marcher les programmes? En quoi p.z dans le code Cpp serait juste un bug?

---

Ce monsieur parle de l'importance des langages de programmation.

Il parle plutôt à des non programmeurs (une rencontre Mathématiques).
Des gens qui ne se sont peut être pas posés de questions sur l'intérêt de diversité des langages informatiques.

Dans ce cadre, il essaie d'expliquer pourquoi il est préférable d'utiliser des langages typés voire des outils de vérification formel ou des langages formels pour certaines classes d'application (notamment les systèmes critiques).

Le problème de Python peut être aussi illustré par:

Code:

---

1 2 3 4 5 6 7 8 9 10

>>> def f(x): ... if x: ... print(a) ... >>> f(False) >>> f(True) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in f NameError: name 'a' is not defined

---

On mettra le "bug" en évidence qu'en passant dans la bonne branche du test.

Avec de gros programmes, impossible de tester toutes les conditions qui permettraient de passer dans toutes les branches du code.

C'est ce qui fait l'avantage d'un langage typé.
Et ce n'est pas un hasard, si les développeurs de dropbox ont convaincu V.Rossum de pousser un peu dans ce sens (histoire qu'on puisse développer de gros programmes avec Python)

Le bonhomme est convaincu de l'intérêt des langage formel qui permettent de fabriquer des codes sans erreur (et sans avoir à les tester).

Sans dénigrer l'intérêt de ces langages, ils sont nécessaires à un pouième des applications (les applications dites "critiques"), il est très difficile d'avoir le niveau d'abstraction qui va bien pour s'y former, quand à pouvoir se faire recruter par une équipe qui travaille sur ce genre de projets,...

Citation:

---

Envoyé par flapili

quand je vois certaines personnes assistant à ça et qui rigolent / le sourire au coins de la bouche ça je me dit qu'ils se moquent surement de ce charlatan

---

On peut penser que les membres du College de France sont un peu "has been" néanmoins le traiter de charlatan est pour le moins irrespectueux.

Quand un monsieur aux cheveux blancs avec un CV élogieux prend le temps de partager ses réflexions sur son métier, on essaie de comprendre ce qu'il raconte (le fond) plutôt que de s'offusquer sur la forme (même s'il en fait des caisses)...

Ce qui ne veut pas dire de mettre un mouchoir sur son esprit critique et boire ce qu'il raconte comme du petit lait... (que ce soit lui ou quelqu'un d'autre d'ailleurs).

- W




- W

Citation:

---

Envoyé par MissLoop

Mais en ce qui concerne l'utilisation d'un langage plus performant, peut être pouvez-vous m'éclairer? J'ai visionner récemment une vidéo d'un cours de Gérard BERRY captée au CIRM sur "L'importance des langages en informatique"

Il fait dans ce cours une comparaison entre un code Cpp et Python (44:33 à 48:20), pour conclure que "...côté sécurité de programmation...c'est le plus bas de gamme qu'on ai fabriqué depuis l'Assembleur..." en parlant de Python.
Ce qui m'échappe dans cette démonstration : En quoi la faute d'orthographe fait marcher les programmes? En quoi p.z dans le code Cpp serait juste un bug?

---

Je viens de regarder le passage qui compare la programmation objet C++ et Python.
C'est juste affligent de conneries.
D'abord il compare un code qui ne fait pas la même chose (@45:53) puis il insiste sur un principe qu'il ne semble pas comprendre.
À croire qu'il ne sait pas ce qu'est une instance et une classe.


Ce qui est sûr et c'est reconnu, si on développe en Python, et en règle générale en langage faiblement typé et non compilé, c'est qu'il faut être beaucoup plus rigoureux sur son code si on veut éviter des erreurs qui vont apparaître à l'exécution.
Et si vous souhaitez réaliser un gros projet alors les tests unitaires sont fait pour vous.

En C on peut très bien écrire de la merde et se corriger 100 fois jusqu'à que ça compile, et là c'est sûr que ça marchera, la syntaxe sera correcte mais ça n'empêchera pas des erreurs sémantiques, quelque soit le langage.

J'ai arrêté la vidéo après 3 mn, tellement c'est affligeant, le genre de personne qui est resté dans la vision des années 90, à vouloir redévelopper la roue à chaque projet.
Combien de fois des développeurs bornés qu'ils soient novices ou non ont recréé et continue à créer des outils / librairies qui existent déjà et pour au final produire un truc bancal.

Voici un exemple pour illustrer à quel point quelque chose qui parait simple peut vite être casse-tête :
Comment parser un fichier CSV : https://sebsauvage.net/wiki/doku.php?id=csv

Le rapport ?
Remettre en cause Python et les langages haut niveau en général c'est remettre en cause des années d'expériences pour aboutir à des codes aboutis et performants, comme le font les librairies, les framework.

Si avec quelques lignes HTML vous arrivez à écrire une page web, c'est parce que derrière il y a du codage, très certainement réalisé en C pour permettre d’interpréter et de réaliser des fonctions de haut niveau, le rendu de la page.
En python c'est pareil, que le langage soit flexible ou pas, que la syntaxe soit verbeuse ou concise, ils apportent leurs avantages et leurs inconvénients. On n'en a pas la même utilité et on peut très bien coupler du bas et haut niveau pour tirer partie du meilleur des deux.

Heureusement que ce genre de personne n'est pas à la tête de l'évolution de la programmation autrement on en serait encore au Minitel 2.0 à vouloir tout coder en bas niveau.


Et à l'inverse, vouloir tout coder en Python n'est pas non plus une bonne chose.
Si vous devez réaliser de gros calculs sur des quantités phénoménales de données, alors il y a des librairies Python faites pour manipuler des objets/conteneurs de plus bas niveau et qui vont réaliser des opérations C/C++ bien plus performantes.

Les bases : pour manipuler / analyser des données / nombres : NumPy, Pandas
Pour manipuler des objets C et appeler des fonctions C directement, depuis une DLL ou autre : ctypes

Je peux comprendre votre besoin de vouloir à tout prix utiliser la bonne syntaxe pour optimiser, car en Python il y a souvent des milliers de façon différentes d'écrire un code et le temps d'exécution peut être très différent si on s'y prend mal.
Et comme l'a fait remarqué flapili.
Le terminal stdout/stderr n'a pas pour vocation d'afficher des milliers de lignes à la seconde, ce n'est pas un flux vidéo, il a pour but de faire un retour utilisateur/débug, d'afficher un échantillonnage d'un tableau par exemple.

À la limite vous pouvez rediriger le flux std dans un fichier, ce sera bien plus efficace.
Python - Logging HOWTO

À moins que vous ne vouliez faire un jeu dans un terminal ça n'a pas vraiment d'intérêt de s'en soucier.

Citation:

---

Envoyé par flapili

En faite ce que je voulais dire par là c'est qu'il n'y a pas de raison d'essayer de réécrire print dans le sens où cette fonction est tout à fait optimisé pour ce qu'on lui demande de faire (sérialisé un object avec ses méthodes __str_ / __prep__) pour y écrire dans un flux.
print est avant tout utilisé à des fin des debug/test et la différence de performance entre write et print est d'un coté relativement faible et ne répondent pas aux même besoin.

---

Ok effectivement formulé de cette façon c'est beaucoup plus clair et infiniment plus pertinent, merci pour votre remarque.

@flapili & YCL-1
En ce qui concerne la vidéo de Gérard Berry au Centre International de Rencontres Mathématiques :
Entendons nous bien il n'est pas question de provocation. Même si, je m'en rends compte maintenant, le rapport "sécurité-bas-de-gamme-assembleur-python" en appel au visionnage était manifestement du plus mauvais effet. Mais au delà des passions qu'une piètre entrée en matière peut engendrer et donc malgré l'image has been (en toute modération) que peut revêtir à vos yeux Gérard Berry dans ce laps de temps de près de quatre minutes (sur un cours de près de deux heures pour sa seconde partie), il y a un point de vue. Seulement un point de vue, celle d'un informaticien (https://fr.wikipedia.org/wiki/G%C3%A9rard_Berry).
Dans sa comparaison Cpp / Python lorsque j'ai visionné la vidéo je me suis dit qu'il serait sûrement plus judicieux d'ajouter un self.z dans la déclaration de classe en Pyhton, c'est tout.

Citation:

---

Envoyé par wiztricks

Ce monsieur parle de l'importance des langages de programmation.

---

Pas seulement.

Citation:

---

Envoyé par wiztricks

Il parle plutôt à des non programmeurs (une rencontre Mathématiques).
Des gens qui ne se sont peut être pas posés de questions sur l'intérêt de diversité des langages informatiques.

---

Voici la présentation de la conférence :
"Une importante réforme de l'éducation a été mise en place dans les «Classes préparatoires» françaises en septembre 2013, et notamment en ce qui concerne l'enseignement de l'informatique. Cette réforme est désormais terminée.
Cet atelier fait donc partie d'un programme de formation générale pour les enseignants du CPGE. En tant que l'un des lieux ayant participé à la formation des professeurs d'informatique au cours des 25 dernières années, nous pensons que «l'atelier Luminy» (CIRM) a un rôle clé pour accompagner les changements dans ces domaines." https://conferences.cirm-math.fr/1597.html

Citation:

---

Envoyé par Sve@r

Si list4[i] contient i, alors vaut mieux écrire list4[i]=str(i). On évite au-moins une indirection.
Mais plus simplement autant faire directement list4=' '.join(str(i) for i in range(101)).

---

Merci, j'avais pas pensé à ça.
Ce à quoi j'ai pensé:

Code:

---

list4 =list(map(str, list4))

---

pour un éventuel retour:

Code:

---

list4 =list(map(int, list4))

---

souple quoi :mouarf:

Citation:

---

Envoyé par MissLoop

Ce à quoi j'ai pensé:

Code:

---

list4 =list(map(str, list4))

---

---

Oui c'est vrai, j'ai pas le réflexe "map". Mais pourquoi remplir list4 pour le re-remplir après ? Quand on te rend de la monnaie dans un magasin, est-ce que tu commences par la ranger dans ta poche puis enlever ta main puis remettre ta main dans ta poche pour reprendre la monnaie pour la ranger dans le portefeuille ???
list4=list(map(str, range(101)).
Ensuite si list4 n'a pas besoin d'évoluer, je préfère alors utiliser le tuple => list4=tuple(map(str, range(101)) mais là c'est une question de goût personnel

Citation:

---

Envoyé par MissLoop

pour un éventuel retour:

Code:

---

list4 =list(map(int, list4))

---

souple quoi :mouarf:

---

Souple comme ranger la monnaie dans sa poche avant de la ranger dans son portefeuille :mouarf: list4=tuple(range(101))

Citation:

---

Envoyé par MissLoop

En ce qui concerne la vidéo de Gérard Berry au Centre International de Rencontres Mathématiques :
Entendons nous bien il n'est pas question de provocation. Même si, je m'en rends compte maintenant, le rapport "sécurité-bas-de-gamme-assembleur-python" en appel au visionnage était manifestement du plus mauvais effet. Mais au delà des passions qu'une piètre entrée en matière peut engendrer et donc malgré l'image has been (en toute modération) que peut revêtir à vos yeux Gérard Berry dans ce laps de temps de près de quatre minutes (sur un cours de près de deux heures pour sa seconde partie), il y a un point de vue. Seulement un point de vue, celle d'un informaticien (https://fr.wikipedia.org/wiki/G%C3%A9rard_Berry).

---

Mouais. On peut être informaticien, avoir fait polytechnique, être une "grosse tête" et être aussi complètement à côté de la plaque. Déjà son Point &p=*new Point(1, 5) que n'importe quel dev normal aurait écrit Point p(1, 5) en est un bon indice et surtout sa blague à la con sur la syntaxe Python avec son "souligné souligné init souligné souligné ça sent le hack à plein nez" avec tous les gros blaireaux du public qui rient bêtement derrière. Mais en réalité on ne compare pas les langages entre eux car ils n'ont pas le même but. Et surtout on ne vient pas dire "cette instruction Python est peut-être un bug". Ce n'est pas le fait de pouvoir rajouter p.z=7 dans l'instance qui est un bug, c'est le faire s'il ne fallait pas le faire qui l'est. Mais c'est pareil pour toutes les instructions valides de tous les langages. Je vais pas aller dire "oh je peux mettre break au milieu d'une boucle C ce qui fera planter la boucle donc le break est un bug du C".
Ce n'est pas parce que quelqu'un fait une connerie en Python qu'il ne pourrait pas faire en C++ que Python est plus mauvais que C++. Parce qu'il y a aussi des conneries qu'on peut faire en C++ et qu'on ne peut pas faire en Python => int tab[10]; tab[500]=123 par exemple.

Citation:

---

Envoyé par MissLoop

Dans sa comparaison Cpp / Python lorsque j'ai visionné la vidéo je me suis dit qu'il serait sûrement plus judicieux d'ajouter un self.z dans la déclaration de classe en Pyhton, c'est tout.

---

Oui, c'est effectivement (ici) ce qu'il y a de plus simple à faire. Moi aussi dans une classe je définis toujours tous ses attributs dans le __init__ même si certains attributs ne sont remplis que plus tard (habitude venue du C). D'où ma remarque précédente. On ne produit pas un bug exprès pour venir dire ensuite "oh regardez ce langage tout pourri car créateur de bugs".

Bonjour,

Juste un petit ajout. Je reprends le petit exemple de wiztricks:

Code:

---

1 2 3

def f(x): if x: print(a)

---

L'appel à f(False) retourne None (il n'y a d'instruction return), mais l'appel à f(True) renvoie une erreur puisque "a" n'est pas une variable utilisée avant). Il s'agit d'un problème général lié à l'interprétation. Mais ça peut être grave, puisqu'un programme complexe distribué peut planter plusieurs mois après lorsque les conditions d'exécution font passer le code à un mauvais endroit...

Le remède pour moi est d'utiliser systématiquement un analyseur de code comme pylint (https://pypi.org/project/pylint/). Ce n'est pas un programme parfait, mais il détecte assez bien ce genre de problème. Dans le cas ci-dessus, il donnera, accompagné du numéro de ligne et de caractères:

Code:

---

E0602: Undefined variable 'a' (undefined-variable)

---

Citation:

---

Envoyé par Sve@r

Mais pourquoi remplir list4 pour le re-remplir après ? Quand on te rend de la monnaie dans un magasin, est-ce que tu commences par la ranger dans ta poche puis enlever ta main puis remettre ta main dans ta poche pour reprendre la monnaie pour la ranger dans le portefeuille ???

Souple comme ranger la monnaie dans sa poche avant de la ranger dans son portefeuille :mouarf: list4=tuple(range(101))

---

Oui tu as raison, en fait je pensais pouvoir remplacer .join() par map.
Mais ça fait pas la même chose.
Et même:
list4=' '.join(str(i) for i in range(1, 101))
N'est pas adapté à ce que je voulais faire... en fin de compte.

Donc ce que je voulais faire :
J'ai une liste de nombre au départ (commençant par 1, ou plus précisément ne commençant pas par 0) que je veux conserver et que je vais afficher avec sys.stdout.write.

Ce que j'avais envisagé:
Je passe list[int] en list[str]
Je passe list[str] en str
J'affiche (ligne par ligne).
je passe str en list[int]

Mais suite à tes réponses et après avoir "re-discuté" avec "Test et Prise de tête" je me suis rendue compte qu'il y a plus simple quand on finit par comprendre le fonctionnement des instructions que l'on utilise :

Code:

---

1 2 3 4

import sys list4 =list(range(1, 101)) for i in range(len(list4)): sys.stdout.write(str(list4[i]) +'\n')

---

Je me suis totalement emmêlée les neurones en étant persuadée qu'il fallait passer de list[int] en list[str] en str pour pouvoir utiliser sys.stdout.write(str(list4[i]) +'\n') et qu'il fallait donc repasser la liste en int après l'affichage (amusant non?). La raison de cette CONfusion, très certainement un print(type()) mal placé,... très mal placé, pour ne pas dire totalement déplacé et des tests pour le moins aléatoires.

Enfin heureusement que la conversation a continué après la résolution (merci @flapili, YCL-1 & wiztricks) sinon j'en serais toujours au même point voire pire, avec mes croyances "animistes"...

Citation:

---

Envoyé par Sve@r

Mouais. On peut être informaticien, avoir fait polytechnique, être une "grosse tête" et être aussi complètement à côté de la plaque. Déjà son Point &p=*new Point(1, 5) que n'importe quel dev normal aurait écrit Point p(1, 5) en est un bon indice et surtout sa blague à la con sur la syntaxe Python avec son "souligné souligné init souligné souligné ça sent le hack à plein nez" avec tous les gros blaireaux du public qui rient bêtement derrière. Mais en réalité on ne compare pas les langages entre eux car ils n'ont pas le même but. Et surtout on ne vient pas dire "cette instruction Python est peut-être un bug". Ce n'est pas le fait de pouvoir rajouter p.z=7 dans l'instance qui est un bug, c'est le faire s'il ne fallait pas le faire qui l'est. Mais c'est pareil pour toutes les instructions valides de tous les langages. Je vais pas aller dire "oh je peux mettre break au milieu d'une boucle C ce qui fera planter la boucle donc le break est un bug du C".
Ce n'est pas parce que quelqu'un fait une connerie en Python qu'il ne pourrait pas faire en C++ que Python est plus mauvais que C++. Parce qu'il y a aussi des conneries qu'on peut faire en C++ et qu'on ne peut pas faire en Python => int tab[10]; tab[500]=123 par exemple.

---

Ok, en fait dans cette vidéo il s'agit uniquement d'un point de vue.
C'est le point de vue d'un informaticien qui dispense maintenant des cours et qui s'adresse à des enseignants en informatique. C'est un cours de prof à des profs.
De part son CV et le prestige des lieux où il enseigne (et à enseigné), sa personnalité, sa décontraction, son verbe il semble faire autorité en tant que prof "dominant".
Il est toutefois vrai que dans cette vidéo il raconte des conneries, notamment sur la MAO, et qu'il les justifie très aléatoirement.

NON Mr Berry, Mac n'est pas uniquement le top en MAO,
NON Mr Berry Linux (à mon grand désespoir) n'est pas une alternative plausible et
NON Mr Berry Windows (à mon grand désespoir également) n'est absolument pas à la ramasse dans ce domaine.

Et en plus de justifier cette position en affirmant qu'on connaît du monde (ou que l'on travaille avec (je ne me rappelle plus)) à l'IRCAM...

Mr Berry sachez que l'IRCAM produit des softs pour Mac et Windows.
Mr Berry sachez que les plugins, instruments, effets, modulation, synthé, DAWS... sont légions sous Windows et qu'il est facile de les essayer avec toutes leurs fonctionnalités.
Mr Berry sachez que la gestion du son sous Nux est particulière (et parfaitement merdique (là c'est mon avis, encore une fois à mon grand désespoir)), que la gestion matérielle est parfois problématique et surtout que les softs qui gèrent la connexion du son avec les différents instruments, plugins, etc... sont ou bien instable et ergonomique ou bien stable mais pas très ergonomique.

Mais le sujet n'est pas la MAO, d'accord... simplement pour dire que j'avais relevé dans cette vidéo des signes qui confortaient, j'ai la faiblesse de le croire, l'éveil naturel de vigilance qui anime mon sens critique.
Ce que j'ai cherché dans son CV, c'est surtout son rapport avec le langage Esterel. Parce qu'il en parle dans son intervention et que la syntaxe de ce langage (d'après le court extrait qui y est présenté) m'a semblé encore plus simple que Python.

Alors effectivement, avec "l'odeur de hack" et "secu bas de gamme", dans ces quatre minutes Python en prend pour son grade... J'ai vu la vidéo en entier et à mon sens, sa vanne de syntaxe et la filiation Assembleur sont surtout mentionnées pour marquer les esprits de l'assistance, (en tant que prof vous enseignerez ou vous enseignez déjà Python donc attention à la sécurité ne l'oubliez pas), ce qui, la sécurité des programmes informatiques, à l'air d'être un cheval de bataille pour Berry.
Mais la sécurité dans l'extrait des quatre minutes vaut aussi pour Cpp.
Quand il parle de la faute d'orthographe qui fait marcher les programmes, c'est vers le cas de Cpp qu'il se tourne et qu'il est "prêt à parier que p.z c'est juste un bug" pour ensuite revenir manifestement à Python en affirmant (les mains en l'air) "et là le bug on le voit plus".
Il ajoute (après la "filiation" Assembleur) comme pour "JavaScript pour arriver à faire un bug en Pyhton c'est pas facile..."
Et il pose ensuite une question : "Est ce que l'informatique c'est écrire des programmes ou c'est pas faire de bugs? C'est un choix très important."

Après avoir vu cette vidéo, on peut se dire, objectivement que Gérard Berry aime les mathématiques, qu'il a un penchant pour les langages fonctionnels en particulier CAML (peut être parce que le cours est dispensé au CIRM mais pas seulement en définitive, encore une fois, là c'est mon avis), qu'il aime les programmes bien conçus, donc bien stable, donc bien secure.
Contrairement à ce que l'on pourrait croire après le visionnage des quatre minutes de "l'affront", je ne serais pas étonnée (pour avoir vu la vidéo en entier) qu'il serait plus enclin à apprécier Python plutôt que C, Cpp ou Java (one more time : mon avis).

D'ailleurs (et voici pour les sportifs une formidable occasion de ranger Berry dans la catégorie des sous débiles séniles) il trouve Scratch canon!??? Il relève deux défauts cependant, il n'y a pas de delete (il me semble, j'ai regardé la vidéo certes ma yé soui pas oune machine) et il faudrait une version écrite de Scratch (peut être parce que la dernière version de Scratch est écrite en JavaScript (en fait je crois que JavaScript c'est vraiment pas son truc)).
Et oui car le but de cet atelier c'est de causer éducation et enseignement de l'informatique : https://conferences.cirm-math.fr/1597.html

Non vraiment, à mon avis de débutante, il me semble que pour juger si il sait ou non de quoi il parle, on doit visionner la suite de l'affront pythonesque (48:20 à 52:37 "Parallélisme : le principe de compositionnalité", ça continu ensuite avec les types de programmation et leurs langages (où il remet en avant un langage fonctionnel, Erlang)).

Pour ma part j'ai choisi Python parce qu'il est simple dans sa syntaxe.
Et si je crois en quelque chose c'est en la puissance de la simplicité.
Mais surtout Python m'évite le strabisme infernal que d'autres langages engendrent entre syntaxe et algorithmique.
Après avoir vu cette vidéo je voulais faire deux post sur le forum en mentionnant le passage de la mort, 1 vers Cpp et l'autre vers Python histoire de comprendre et d'apprendre, oups mauvaise idée...
Et puis si flapili n'avait pas "réveillé" le sujet qui je le rappelle était résolu je n'aurais jamais posté cette vidéo...
NON JE DÉLIRE, heureusement que flapili s'en est mêlé sinon j'en serais toujours à chercher à typer des listes pour utiliser sys.stdout.write (la honte) :calim2:.

@YCL-1
Merci pour toutes ces bonnes infos.

@wiztricks
Merci pour l'exemple.

@tyrtamos
Merci pour le complément à l'exemple de wiztricks.
J'adore votre avatar.

Citation:

---

Envoyé par MissLoop

Ce que j'avais envisagé:
Je passe list[int] en list[str]
Je passe list[str] en str
J'affiche (ligne par ligne).
je passe str en list[int]

---

Bon je pense que t'as compris... mais je vais quand-même le redire: ça c'est pas bon. On ne transforme pas une donnée type A en type B parce que c'est plus pratique pour un truc puis la retransformer en type A pour continuer le travail. Déjà ça coûte du temps CPU, et t'es pas à l'abri que la transformation fasse perdre de l'info.
Tu as parfaitement le droit d'avoir besoin de ce truc dont je parle (dans ton cas c'est un affichage). Alors tu crées une copie de ta donnée adaptée à ce truc puis une fois le truc fini, tu oublies ta copie et tu reviens à ta donnée de départ qui, elle, n'a pas été modifiée.
Ensuite il est possible que Python offre des syntaxes permettant à la fois la copie et le travail (comme le ' '.join(str(x) for x in data)) si c'est le cas c'est bonus sinon tant pis, tu te coltines la copie à la mano avec ton for i in range(len(list4)): sys.stdout.write(str(list4[i]) +'\n') mais ça ne remet pas en cause le pricipe de base: on ne touche pas à la donnée d'origine.

Citation:

---

Envoyé par MissLoop

Code:

---

1 2	for i in range(len(list4)): sys.stdout.write(str(list4[i]) +'\n')

---

---

Code:

---

1 2 3 4 5 6 7

for l in list4: sys.stdout.write(str(l) +'\n')   for l in list4: sys.stdout.write("%s\n" % l)   sys.stdout.write("".join("%s\n" % l for l in list4))

---

;)

Citation:

---

Envoyé par Sve@r

Alors tu crées une copie de ta donnée adaptée à ce truc puis une fois le truc fini, tu oublies ta copie et tu reviens à ta donnée de départ qui, elle, n'a pas été modifiée.

---

Ok, quand tu parles de copie moi je vois : data_A et data_A_copy, j'ai deux données identiques au départ.
Dans mon histoire d'affichage (après correction) j'ai toujours qu'une seule donnée?

Citation:

---

Envoyé par MissLoop

Ok, quand tu parles de copie moi je vois : data_A et data_A_copy, j'ai deux données identiques au départ.

---

Pas forcément identiques. Si tu as une data_A de type list[int] et que tu as besoin, pour l'affichage, d'une list[str], alors tu crées data_A_copy comme list[str] à partir de data_A qui, elle, ne change pas. Stricto-sensu data_A et data_A_copy ne sont donc pas identiques.

Citation:

---

Envoyé par MissLoop

Dans mon histoire d'affichage (après correction) j'ai toujours qu'une seule donnée?

---

Disons que quand data_A_copy ne te sert plus, tu peux alors l'oublier allègrement. Tu remarqueras d'ailleurs que dans ton dernier code où tu dis avoir trouvé comment afficher (ainsi que dans mes 3 exemples qui réécrivent ledit code de façon différente), il n'y pas eu création de "data_A_copy" (enfin il y a eu création "à la volée" donc équivalent à création+traitement+oubli).

Citation:

---

Envoyé par Sve@r

...(enfin il y a eu création "à la volée" donc équivalent à création+traitement+oubli)

---

C'est ça que je voulais savoir. L'avantage avec cette solution c'est que l'on gagne en temps CPU, en mémoire et en prime on n'encombre pas le code inutilement. Bref on code propre!

Citation:

---

Envoyé par Sve@r

Bon je pense que t'as compris... mais je vais quand-même le redire: ça c'est pas bon. On ne transforme pas une donnée type A en type B parce que c'est plus pratique pour un truc puis la retransformer en type A pour continuer le travail. Déjà ça coûte du temps CPU, et t'es pas à l'abri que la transformation fasse perdre de l'info.

---

Alors ça?, je pensais le contraire.
Quant au temps CPU j'y ai absolument pas pensé, je me suis dit qu'en faisant des transformations de type je gagnerai en mémoire plutôt que de faire une copie (ce à quoi j'avais pensé).

Merci infiniment pour toutes ces précisions, tes 3 exemples (particulièrement pédago) et pour ce mantra qui veut que l'on ne remette pas en cause le principe de base:
ON NE TOUCHE PAS À LA DONNÉE D'ORIGINE.