Bonjour @68tjs,
Je ne vois pas pourquoi vous avez verrouillé le sujet :
Personne ne s’est enflammé.
1 Like
Il n’y avait pas lieu de fermer ce fil :
- Pas de manque de respect
- pas d’agressivité
…
Vous ouvrez un fil de discussion et vous le fermez à votre convenance.
Vous abusez 
1 Like
Probablement que Profile - 68tjs - Arduino Forum s'est aperçu qu'il avait posé une question sans réponse possible. Si Python était une mode passagère cela ferait bien 30 ans qu'on le saurait, non ?
1 Like
Bonsoir @hbachetti
Je ne lui fais pas de reproche sur le fond mais sur la forme.
Si maintenant les modérateurs ou modérateurs par dérogation ou ancienneté se mettent à ouvrir et fermer des fils de discussion selon leur bon vouloir, ça n’est pas normal
Bonne soirée.
1 Like
Absolument d'accord avec toi.
1 Like
Je ne vois pas non plus la raison de cette fermeture dans la mesure ou chacun peut mettre le sujet en sourdine si il le souhaite.
1 Like
Il n’y a eu aucun manque de respect envers les uns et les autres. Le ton n’est pas monté.
De plus @68tjs marque son dernier message comme étant la solution
@68tjs ne m’avait pas habitué à ce genre d’égarement
Je ne comprends pas ce comportement injustifié.
1 Like
C'est le bar, tu es libre d'ouvrir un fil de discussion sur le sujet qui te plait.
Mais bon, on peut échanger des messages pendant 10 ans sans trouver de raison qui justifie C/C++ plutôt que Python, Forth, LISP ou BASIC et ça risque effectivement de partir en vrille.
Personnellement, je m'en balance complètement. J'utilise le langage dont j'ai envie en fonction du besoin et de la cible et je ne ressens pas le besoin de faire du prosélytisme.
EDIT: A la limite, si je devais fermer un fil de discussion ce serait celui sur Arduino Factory qui commence à déraper. Parce que bon, on a tout dit sur le sujet et je ne pense pas qu'il soit nécessaire d'en rajouter.
Bonsoir @fdufnews,
Là tu parles du fond alors que moi je critique la forme.
Ce n’est pas parce qu’on dispose du pouvoir de fermer des discussions que l’on doit en abuser. Pour moi il s’agit simplement d’un abus.
Malgré une divergence sur un point peu important à mes yeux, je pense que @68tjs est plutôt sympathique , je le définirai comme le « bon père de famille » qui manifeste souvent de l’empathie envers les autres. Bref c’est pas un méchant
Mais il vient de commettre une erreur, il se discrédite car il doit donner l’exemple !
Pour être respecté, il faut être respectable.
Malgré tout, tout le monde peut commettre une erreur, moi le premier
Envoie un message personnel @68tjs , il peut très bien rouvrir le fil.
Il a lu mes messages, la balle est dans son camps
Bonne soirée.
Je l'ai fermé parce que tout avait été dit et que je sentais le ton monter par moment.
Mon but n'était pas de fiche la pagaille en lançant un sujet polémique..
Bon il semble que j'ai obtenu l'effet inverse,
Désolé.
Je rouvre le fil.
Merci,
Vous pourrez toujours le fermer si le ton monte ou bien il sera fermé automatiquement au bout de 6 mois.
Merci et bonne soirée ou plutôt bonne nuit.
Cordialement.
Bonjour philippe86220
LEs questions de 68tjs étaient à mon sens très fortement biaisées pour débiner Python:
savoir si c'est une mode n'a pas d'interet
dire que python est lent parce qu'il est interprété est une tarte à la crème
- python tapé au clavier est effectivement interprété, sauf si on définit une fonction (ou cas analogue); là, comme dans
- l'importation de bibliothèques écrites en Python, il est pseudo compilé vers du byte code, qui est traduit à son tour. (donc plus lent que s'il avait été du C compilé avec des optimisations raisonnables)
- dans le cas où on fait appel à des bibliothèques liant à du C, C++, Fortran , et où on traite des gros tableaux; l'éventuelle lenteur de Python est invisible en pratique (entraînement/test de DNNs, traitements d'image, calculs scientifiques, gestion de youtube et de duolingo)
compiled - If Python is interpreted, what are .pyc files? - Stack Overflow est très féroce avec ce genre de question, tout en donnant des explications éclairantes
La seule vraie question était la question de la gestion des bibliotèques, qui peut être calamiteuse (gestionnaire de bibliothèque trop laxiste)
Pour comprendre, pip (l'installateur de paquets) est suffisamment performant pour qu'on puisse installer des biblothèques totalement incompatibles (m^me d'une version de la même bibliothèque à l'autre, le nombre, l'ordre et la signification des arguments d'une même fonction peuvent changer).
Ceci peut être caché en prenant des bibliothèques sélectionnées soigneusement par Debian, Fedora ou autres
Dès qu'on va sur pypi (le dépôt officiel ), on court des risques; je ne parlerai pas de github.
Pour votre info, la structure d'un paquet Pypi est très rudimentaire:
https://learnopencv.com/tag/pypi/ la décrit ainsi:
root directory
configuration files
src
package1
modules
subpackage1
Pas de docs, pas d'exemples, pas de jeu d'essai... Ajoutez à ça que s'inscrire à PyPi nécessite -et ça suffit, de fait- d'avoir un compte github pour mettre ce qui vous passe par la tête, il ne faut pas s'étonner que sur quelques dizaines de milliers de bibliothèques, il y en ait pas mal d'inutilisables... Abondance de biens nuit.
Ensuite, il y a github ou des whl que recommandent les tutos...
Là, c'est indescriptible.
On peut un petit peu se prémunir de toutes les consèquences d'un tel désordre en utilisant venv venv — Création d'environnements virtuels — Documentation Python 3.12.0
C'est a situation sur PC, RPi et autres plateformes ayant un systeme d'exploitation; avec les paquets Linux (et vous avez même un classement thématique sous Debian) ou un bibliothèques bien choisies, vous pouvez obtenir très vite de jolies choses et trouver que l'herbe est plus verte que chez Arduino...
Maintenant, sur microcontroleurs
AdaFruit fabrique CircuitPython, un clone de micropython et diffuse sur github des bibliothèques (avec exemples, doc, tutoriaux) pour chacun des peripheriques RPi et ESP et picoPi qu'ils vendent (elle fonctionne aussi sur RPi.. avec quelques efforts). Naturellement, quand ils cesseront de les vendre, ces bibliothèques e seront plus maintenues.
MicroPython évolue lentement (en jouant avec sur picopi2040, je ne lui ai pas encore trouvé de défauts.
Sa lenteur (eventuelle) ou la préexistence de bouts de code en C(++) peuvent être cachées par la possibilité d'étendre micropython, le mode d'emploi de cette manoeuvre est lisible MicroPython external C modules — MicroPython latest documentation
Donc, micropython n'a pas -encore- les défauts de python sur PC (on ne peut pas faire tenir autant de sottises dans un microcontrôleur que dans un PC) ... ce qui est plutôt sympa, pour le moment.
Bonjour @coloneldeguerlasse,
La divergence ne se situe pas à ce niveau, elle est peu importante.
Je respecte beaucoup @68tjs pour ses compétences en matière de micro-contrôleurs et d'électronique. J'ai beaucoup d'estime pour ses qualités humaines que j'ai déjà citées :
Voilà c'est tout, pas la peine d'aller chercher midi à 14 heures. Il faut maintenant sortir des polémiques.
Bonne journée.
Comme je l'avais déjà précisé, les réponses du "colonel" ne me convenaient pas.
Je ne me permettrai jamais de dire que ses réponses sont mauvaises, => je trouve qu'elles sont inutilement polémiques.
Je le respecte comme chacun ici, j'ai seulement pris la décision de le placer en mode sourdine. Donc ses interventions sont cachées.
Je viens de détecter par la réponse de Phillippe qu'il m'a mis en cause. J'ai donc activé la lecture du message #14
Ce qui m'est reproché est tellement ridicule ! Je n'arrive pas à imaginer que l'on puisse avoir de telles pensées. Je ne suis pas prêt de lever le mode sourdine.
Mon message ne parlait pas seulement de python.
A ce que j'ai compris :
Pascal et le C ont été en concurrence.
Le C l'aurait emporté parce qu'il était plus permissif.
D'après ce que j'ai compris, le C permet d'écrire hors de l'espace réservé pour un tableau et fiche le bazar, Pascal ne le permetrait pas.
Le python serait lui aussi plus strict que le C, => est-ce vrai ce qu'on peut lire ?
Je lis maintenant que Rust vient d'être accepté comme langage pour le développement du noyau Linux parce qu'il est moins permissif que le C (toujours, si j'ai bien compris).
Est-ce un retournement de tendance ?
Savoir si les bibliothèques existent et où les trouver est déjà entrer dans le détail.
Il est toujours possible de se prendre par la main et de faire un tuto sur quelles cartes peuvent se programmer en Python et comment utiliser Python.
Merci Philippe, entièrement d'accord il y a des sujets qui sont pollués par des polémiques inutiles.
s:sourdine:[roulementtDeMecaniques]sourdine[/roulementDeMécaniques]:
Incoherent avec le titre "Python :effet de mode ou avantage", votre titre
Effectivement, sur 3 questions, deux n'avaient pas de sens, et, avec un effort de documentation minimaliste, stackoverflow en évacuait une avec ironie ... en bon anglais...
La troisième (librairies) est plus que gênante pour pas mal de paquets Python: elle méritait d'être détaillée....avec respect (stackoverflow vole au secours de dizaines de victimes de malédiction des dépendances liées à la gestion chaotique de PyPi, avec un talent respectable et admirable).
La guerre de Troye et la concurrence entre C et PAscal n'ont aucun rapport avec le sujet
C'est faux (pas de contrôle des types)
Hors sujet. (votre sujet)
Si vous êtes réellement curieux et que vous ne cherchez pas à entrenir de la confusion, posez donc la question à Stackoverflow (ils savent évacuer les questions qu'ils jugent stupides ou qui sont redondantes... et sanctionner les questionneurs maladroits)
Si on ne sait, ni si elles existent, ni où elles sont, on est bien avancé
Redondant de chez inutile:
AdaFruit -tant qu'il les vend- et micropython ont depuis des lustres des modes d'emploi pour pas mal de cartes et des tutos....
Bonjour philippe86220
Je pensais que la divergence entre lemodesourdine (il m'appelle bien lecolonel) et vous portait sur un point technique, qui serait peut être à sa place dans ce type de forum -après essais, vous étiez plutôt satisfait de python; à la lecture de radioTamTam , lemodesourdine débinait python par des questions assez grossièrement orientées- et non sur des questions d'humeur.
Oui, l'écrasement mémoire est un point négatif du C.
Tout les langages ne permettant pas un accès directe à la mémoire, ont donc un point positif.
En contre partie, l'accès à la mémoire est normalement un peu plus lent, je crois, point négatif ?
En C, il est courant d'ajouter des détecteurs de débordement mémoire, ce qui bien évidement "ralentit" le programme.
étant habitué au C, j'avoue que je ne fais pas attention à ce point lorsque j'évalue l'intérêt d'un nouveau langage.
Pip n'est pas l'unique gestionnaire de paquet disponible.
Après je ne sais pas si Conda par exemple est plus restrictif que Pip, mais il est largement utilisé.
Pip n'est pas l'unique gestionnaire de paquet disponible.
Après je ne sais pas si Conda par exemple est plus restrictif que Pip, mais il est largement utilisé.
conda peut aller (pas par "default") piocher dans le même dépôt foutraque que pip... les malédictions de dépendance qui hantent un site respectable comme stackoverflow -auquel je sais gré- seront donc les mêmes, sans précautions (précautions:
venv, s'il n'est pas trop cassé;
se tenir aux paquets de sa distribution) .
conda est superflu dans le monde linux -mais pas windows-, et tente de cacher le caractère calamiteux des paquets de Pypi ... en ayant ses propres paquets ("default") . Il n'est pas totalement compatible avec pip (qui a une ribambelle de versions)
Il gère pour le relatif bonheur de milliers de personnes, environ 3000 paquets (un peu moins que R; beaucoup moins que PyPi -si on peut parler de gestion dans ce dernier cas-)
Edité : ce bonheur relatif n'est pas partagé par les utilisateurs de GNUlinux sous ARM64 (RPi et clones), conda se refusant parfois python 3.x - Installing Anaconda on Raspberry Pi 4 with Ubuntu 20.04 - Stack Overflow -à s'en occuper ; dans ce cas, il peut devenir
.... inutilisable...
il rajoute de la confusion sous stackoverflow (mais, comme il y en très peu par ailleurs -c'est un site interessant- , ce n'est pas grave du tout)
Ceci confirme le fait qu'il y a trop de paquets sous Pypi, et pas assez testés.
Et que, quoi qu'en écrive @modesourdine, les paquets de python (pas micropython) sont importants.