Philippe F a écrit 2214 commentaires

J'ai posé des plaques de placo dans ma maison, sans l'avoir jamais fait avant donc avec plus ou moins succès sur le résultat final.

Un artisan est venu à la maison pour un devis sur un autre sujet, et il m'a proposé de travailler un interim pour lui: il a beaucoup de mal à trouver des gens fiables pour ses chantiers.

Moralité: on sait faire plus de choses que ce qu'on imagine !

J'ai eu aussi des phases difficiles sur le plan personnel qui ont rejailli sur ma capacité à effectuer mon travail. C'est généralement pas le bon moment pour changer de carrière ou même de travail car ce type de changement implique une très grande implication personnelle en temps et en énergie, bien plus que ce que tu donnes à l'heure actuelle à ton travail. Et c'est justement là que tu pèches aujourd'hui.

Mon expérience personnelle pour traverser cette période a été de passer à un temps partiel. Il y a trois voies possibles:

Voie Médecin du travail: tu demandes en rendez-vous avec un médecin du travail et tu expliques ta situation et une demande en temps partiel thérapeutique. Ça peut être 50%, 80% ou tout autre chose qui t'arrange.

Je suis bien tombé lorsque j'ai fait cela, le médecin m'a "prescrit" un 50% pendant 6 mois, et je l'ai revue à l'issue de cette période pour passer à 80% pendant les 6 mois suivants. Durant cette période, j'ai bénéficié d'une indemnisation de la sécurité sociale sur la perte de salaire, plus une compensation de mon entreprise (non obligatoire) qui m'a permis de rester financièrement à l'équilibre. Ce temps en plus m'a aidé à gérer mes soucis personnels (un burn-out suivi d'une dépression) et de revenir en meilleur état. J'ai aussi demandé à avoir moins de responsabilité, et le médecin du travail a également contacté ma hiérarchie pour leur demander de ne pas me mettre sous pression.

Le 50% était sous la forme de 1 semaine à 2 jours et 1 semaine à 3 jours, ce qui me permettait d'avoir des longues périodes de 4 ou 5 jours entre deux moments de travail, qui furent précieuses pour me reconstruire et m'occuper de moi.

Si le médecin du travail te prescrit cela, l'employeur ne peut pas refuser. Suivant la taille et l'ambiance de l’entreprise, ils peuvent le prendre plus ou moins bien. J'ai perso eu des retours plutôt positifs des entreprises et des RH.

Je connais d'autres personnes qui ont suivi cette démarche, avec des résultats plutôt positifs et des médecins du travail compréhensifs. Il y a bien quelques exemples de médecin qui te prescrivent une aspirine et basta mais dans mon expérience, ce n'est pas la majorité.

Voie congé parental: ça ne s'applique évidemment que si tu as un enfant en bas age. C'était mon cas, et après cette année de en congé partiel thérapeutique, je suis passé en congé parental d'éducation à 90%, avec une semaine sur deux à 4 jours et 5 jours. Là, j'ai laissé 10% de mon salaire mais j'ai vraiment apprécié d'avoir deux fois tous les mois des week-ends de 3 jours. Ca convenait pile à mon état, j'étais capable de travailler mais le rythme devait être moins intensif qu'auparavant.

Jusqu'au trois ans de ton enfant, tu as droit à un congé parental d'éducation qui ne peut être refusé par ton employeur, seules les modalités exactes peuvent être discutées.

Voie temps partiel classique: mon fils va bientôt avoir trois ans et j'ai prévu de demander un temps partiel à 90% pour conserver le même mode de vie. Cela me donne plus de temps pour moi et pour mes enfants, contre 10% de mon salaire, ce qui compte tenu des rémunérations de nos métiers, est en général gérable. L'entreprise peut accepter ou refuser mais sachant que plusieurs de mes collègues femmes ou hommes sont déjà en 80% avec le mercredi non travaillé, je m'attends à un accord.

Ca fait bizarre de demander un temps partiel alors que tout notre travail est orienté vers la productivité, mais ça nous rappelle à notre condition d'être humain. Et ça le rappelle aussi à notre entreprise.

Ce temps en plus m'a personnellement été précieux, que ce soit pour gérer mes enfants, pour faire des stages de développement personnel, ou pour soutenir mon épouse dans ses changements à elle. Vraiment, je recommande!

J'avoue que je reste fidèle à Sublime. J'ai essayé VSCode qui était globalement pas mal, sauf que plutôt lent et catastrophique pour le debuggage de Python. Du coup, PyCharm (avec le plugin Vi) pour debugger, Sublime Text pour tout le reste. Je regrette pas d'avoir payé ma licence.

Par contre, ma config Sublime s'est dégradée, j'ai maintenant un contraste pourri pour les couleurs et mon mode Vi est moins performant qu'avant, genre certaines commandes ne passent plus bien. J'imagine que je me suis maillé entre les NeoVintageous, Vintage et autres plugins vi.

Peut-être que ton besoin serait plutôt autour de l'annotation de type. Jette un coup d'oeil à mypy et aux tutoriaux sur l'annotation de type (et à ma modeste conférence sur le sujet) pour voir si ça te parle plus.

Il manque donc des informations accompagnant le code source, ce qui est contraire à la licence libre du projet

D'un point de vue strictement juridique, il me semble que livrer les sources sans les build est tout à fait confirme à la GPL. C'est même ce que faisait Redhat et CentOs s'arrachait un peu les cheveux à retrouver les bonnes options de compile.

Je suis d'accord cependant que dans l'esprit, c'est bien de founir aussi le reste.

Ce n'est donc pour le moment pas du libre.

Je crois que tu viens de marquer un point Zenitram.

Il faut absolument garder le **2 , sinon, ça ne pique pas les yeux !

>>> l: Dict[int,int] = { 5:9, **{ v: t**2 for v in d if (t:=v%2) } }

Avec plaisir. Alors, l'explication de texte:

def f(a, /, d, *, e):
    l: Dict[int,int] = { 5:9, **{ v: v**2 for v in d if (t:=v%2) } }
    return l

Pour ce qui des arguments de la fonction f: / comme epxliqué dans la dépêche implique que a peut être passé uniquement en paramètre positionnel, d peut être passé un paramètre positionnel ou par mot-clé et e ne peut peut être passé que par mot-clé.

Concrètement:

>>> f({},{},{})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes 2 positional arguments but 3 were given
>>> f({},{},e={})   # ca marche
{5: 9}
>>> f({},d={},e={}) # ca marche aussi
{5: 9}
>>> f(a={},d={},e={}) # et non, a ne peut pas être passé par mot-clé
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() got some positional-only arguments passed as keyword arguments: 'a'

La partie l: Dict[int,int], c'est juste pour le sport. Ça déclare une variable annotée en tant que dictionnaire avec des clés de type entier et des valeurs de type entier. Pour rappel, les annotations sont ignorées par Python, il faut lancer un outil externe comme mypy pour en tirer quelque chose.

La nouvelle syntaxe permettant du unpacking dans les dictionnaires: {5:9, **dict}, cela crée un nouveau dictionnaire, avec d'une part une clé 5 associée à la valeur 9, et toutes les autres clés-valeurs sont piochées dans le dictionnaire qui suit le **.

Les dict comprehensions {v: v**2 for v in d }, cela crée un dictionnaire dont les clés seront v et associées aux valeur v**2 c'est à dire v puissance 2. La valeur v est piochée en parcourant les clés du dictionnaire d.

On rajoute ensuite un filtre sur les valeurs qu'on pioche dans d via if v%2, en ne gardant que celles qui vérifient v%2 est vrai, c'est à dire v%2 différent de zéro, c'est à dire les nombres impairs. On a donc l'explication du { v: v**2 for v in d if v%2 }.

Le (t:=v%2) permet de stocker la valeur v%2 dans une variable t, c'est la nouveauté du Python 3.8 expliquée dans la dépêche.

En pratique:

>>> t # variable does not exist yet
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 't' is not defined
>>> d={1:2, 2:3, 4:5}
>>> l: Dict[int,int] = { 5:9, **{ v: v**2 for v in d if (t:=v%2) } }
>>> t
0
>>> l
{5: 9, 1: 1}

Je suis un grand fan de Python mais je suis légèrement réservé sur les évolutions du langage ces dernières années.

Quand j'ai commencé le Python, on était en 1.5.2 , et n'importe quel programmeur C, C++ ou Java pouvait lire du code Python sans jamais en avoir vu avant. Ces dernières années, on a fait évoluer la syntaxe de Python pour obtenir des possibilités très intéressantes, mais la syntaxe devient de moins en moins lisible.

Allez, je me lance pour un concentré de truc imbitable:

def f(a, /, d, *, e):
    l: Dict[int,int] = { 5:9, **{ v: v**2 for v in d if (t:=v%2) } }
    return l

Est-ce que quelqu'un qui n'a jamais fait de Python peut me dire à quoi ça correspond ? A mon avis non. Même moi, j'ai du mal quand je vois ça. Pourtant, c'est tout à fait légitime en Python 3.8 . Et si on enlève le t:= à la fin et le / dans l'appel de fonction, ça marche même en Python 3.7 .

Python à ses débuts avait notamment pris soin d'éviter les opérateur trop cryptiques pour les remplacer par des mot-clés (typiquement "and" au lieu de "&&", …). C'était une caractéristiques distinctives de Perl à l'époque qui raffolait des opérateurs imbitables et illisibles à base de caractères imprononçables. Ça soulageait aussi ma vision astigmate.

Je regrette que le "power Python" ressemble de plus en plus à du Perl.

Si j'écris du Python qui doit être relu par mes collègues, je suis attentif à éviter toutes les syntaxes puissantes car j'ai besoin qu'ils comprennent et soient en mesure de modifier mon code.

On est en train de prendre la route du C++, ou deux personnes peuvent toutes les deux prétendre savoir coder en C++ et n'avoir que 10% de savoir en commun !

Je confirme aussi, je bosse dans l'industrie de la carte à puce et les terminaux de paiement ont plutôt tendance à être des bêtes de courses surdimensionnées que des Z80 8 bits.

Il faut voir qu'un TPE doit aujourd'hui savoir faire du TCP/IP, du Wifi, du bluetooth, parfois de la 3G, du NFC bien sur pour le paiement sans-contact, des calculs RSA et DES assez rapide et du stockage relativement sécurisé (ça pèche encore pas mal de ce côté là). Pour toutes ces fonctions, c'est bien plus simple de prendre une stack hardware moderne où tu récupères tout ça dans un seul chip et tu n'as plus qu'à faire le cablage, que de tenter de réduire les coûts du chip pur.

Le soft et le moule plastique ont vite fait de dominer le coût du projet que le pur hardware.

Il faut dire qu'avec ses dîners au homard, il a vraiment dépassé les bornes. Par contre, je ne savais pas que François De Rugy jouissait d'une telle estime !

Kerro nous dit:

C'est plutôt perdre du temps avec des gens qui travestissent les mots pour s'ériger en défenseurs de la veuve et des orphelins.

Je travestis des mots ? Pourtant esclave, il n'y a qu'une seule définition, et c'est bien celle de l'oppression et de l'absence de liberté. Je te mets la définition du Larousse :

Personne de condition non libre, considérée comme un instrument économique pouvant être vendu ou acheté, et qui était sous la dépendance d'un maître. (Il existe encore officieusement de nos jours quelques dizaines de millions d'esclaves en Afrique, en Océanie et en Asie ; leur nombre varie selon les sources.)
Personne soumise à un pouvoir arbitraire.
Personne qui est sous la dépendance complète d'une autre personne : Être l'esclave d'une femme.
Personne entièrement soumise à quelque chose ; prisonnier : Les esclaves de l'argent.

Kerro continue avec :

Maître/esclave n'a jamais eu le moindre rapport avec l'esclavage des humains

Ah oui ? Pourtant, le Larousse n'est pas d'accord avec toi. Il faut croire que les termes techniques des architectures informatiques des années 80 ne sont pas parvenus jusqu'à eux, où qu'ils ont considéré l'usage comme trop mineur.

La réalité, c'est que le sens de ces termes en informatique a été créé par des blancs qui n'avaient pas conscience de prolonger de façon implicite l'oppression qui a régné sur les noirs. Ca n'a rien d'étonnant en soi. Des informaticiens noirs auraient sûrement choisi un autre terme. De même que des juifs n'utiliseront jamais les termes "solution finale" "nazis" et autres pour décrire une quelconque fonctionnalité informatique.

Par contre, continuer à utiliser le terme aujourd'hui alors qu'il y a des alternatives moins chargée, je trouve ça stupide.

Seuls des SJW ayant trop de temps libre (c'est un peu la définition des SJW) s'occupent de ce genre de problème.

Tu as du mal lire, j'ai fait une proposition dans le cadre de mon travail, donc rien à voir avec mon temps libre. Et il n'y avait rien de Warrior puisque c'est une proposition dans le cadre d'une équipe, qui a fait le choix de l'accepter. Et je ne vois pas en quoi c'est Social puisque c'est dans le cadre de mon travail.

En plus, les Social Justice Warrior sont souvent dans une logique de critiquer une personne, une organisation ou une action, ce qui n'est pas mon cas, je me contente de partager une de mes expériences.

Bref, pour moi, tu es complètement à côté de la plaque.

Le produit en question n'a strictement rien à voir avec une base de donnée en effet.

J'ai tout récemment poussé mon équipe à utiliser d'autres termes que Master/Slave dans le logiciel qu'on développe. Ces termes étaient à la fois incorrect d'un point de vue technique, et chargé d'une histoire qu'on a pas besoin de rappeler.

On a atteri sur "Factory" et "Product", le premier servant à fabriquer le 2e.

Bref quand faut brasser du vent il y à toujours du monde…

Ce n'est pas brasser du vent que faire cela. C'est faire preuve d'empathie envers d'autres personnes pour qui ces termes réveillent des souffrances.

En France, on est moins sensibilisé à l'esclavagisme donc ça tilte moins. Par contre, si qq'un utilise les termes "nazis" et "juifs" pour décrire le fonctionnement d'un "thread pool", je suis sûr qu'on perçoit mieux à quel point c'est inapproprié.

Autre raison: le rendu avec des tabs va varier d'un PC à l'autre suivant comment tu as configuré ton éditeur (2 colonnes ? très courant en java ou 8 colonnes obligatoire dans le kernel linux ?). Et comment intepréter la limites de 78 caractères avec des tabs dans une ligne ? Une ligne composé de 70 tabulations et de 7 caractères alphanumériques dépasse la limite de 78 colonnes mais pas de 78 caractères…

Parce que tu gagnes un meilleur salaire si tu utilises des espaces plutôt que des tabulations!

Cf https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/

Les changements progressifs encouragent les dévs à ne pas se crisper sur une version.

Ha ha ha!

Dans quel monde vis-tu réellement ? En dehors de quelques geeks passionnés, la majorité des informaticiens ne s'amuse pas à changer de version pour le plaisir si ça marche déjà. C'est encore plus vrai dans le monde professionnel.

Du coup, tout le monde utilise des versions antidéluviennes et fait des grands bonds en terme de migrations.

A mon boulot, on est bloqué à Python 3.1 pour un certain nombres de logiciels, et ce n'est pas prêt de bouger: l’équipe qui les maintenait n'est plus là. Je vais avoir du mal à justifier auprès de mes chefs qu'on doit maintenir et faire évoluer un nouveau package Python qu'on connait mal, simplement parce qu'on veut utiliser une version plus récente de Python, alors même que celle qu'on utilise marche très bien.

Ce n'est que le couteau sur la gorge que ma boite envisagera cette migration…

Même des très grosses boites comme GitHub ou Dropbox, qu'on ne peut pas trop soupçonner d'être à la rue en terme de technologie ont mis beaucoup de temps pour migrer aux dernières version de Rails et Python.

Quelques lectures intéressantes : https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever/

J'ai pas retrouvé le blog où la mise à jour Rails était décrite mais j'ai souvenir que c'est étalé sur plus d'une année.

utiliser ce langage pour autre chose que des applis de petite taille est handicapant.

Je note quand même que Dropbox et Instagram gèrent une base de plusieurs millions de lignes de Python. Ils ont pas l'air si handicapés que cela…

Perso, je l'utilise sur des applications de toutes tailles. J'ai parfois dépassé les 30 000 lignes. Le seul frein que j'ai rencontré sur Python sur de grosses applications est l'absence de typage des variables/arguments. Problème qui est résolu depuis 5 années avec MyPy.

Pourquoi tu exclues d'emblée l'antispam russe ? Ca parait un vecteur tout à fait naturel et plus simple qu'un keylogger pour récupérer les SMS de sécurité sur un tel. Les applications malveillantes aiment se réclamer de la sécurité, tout comme la Mafia te "protège". Je chercherai plutôt dans cette direction en premier abord.

Tes exemples sont tout à fait pertinents sur des trucs qu'il ne vaut mieux pas faire en Python. En même temps, je suis sûr que tu seras d'accord pour reconnaitre que parmi tout le code qui est écrit dans une semaine aujourd'hui dans le monde entier, la proportion qui concerne les exemples que tu cites est extrêmement infime. Et en dehors de ces cas précis, Python s'avère un langage où les performances sont largement suffisante pour les besoins de ses utilisateurs.

Mon expérience n'est pas universelle mais je peux quand même la partager: depuis 18 ans que je fais du Python, je n'ai fait du profiling pour accélerer mes programmes que 3 fois. Et une fois, j'ai renoncé à écrire un programme (un clone de vi en Python) parce que Python était trop lent. Mais je devais avoir un problème de design car SublimeText y arrive très bien.

D'un autre côté, mon boulot quotidien est d'écrire du code pour des cartes à puce, donc de l'embarqué contraint en vitesse, en taille de code et très fortement contraint en sécurité. On ne fera jamais de Python là-dedans très clairement, seul le langage natif de le puce est approprié (en mélange C / ASM).

Absoluement pas, car dans ce scénario tu fais du développement C/C++ un pré-requis au développement python pour les parties perf critical. Qui suivant ton secteur, peuvent arriver trés rapidement.

Performance, ça reste un terme très générique. De quelles performances on parle réellement ?

1. D'avoir le plus petit runtime en mémoire ? Python est clairement un mauvais candidat, comme tous les langages interprétés et tous les langages à VM.

2. De faire des gros calculs numériques ? Python est très très bien équipé avec pandas, numpy, pytorch et autres projets de calcul scientifique. Ces projets sont écrits en C/C++, leur utilisation en Python te permet donc de bénéficier des perf d'une implémentation native. Il faut vraiment avoir besoin de calculs haute performance très très spécifiques pour tomber en dehors des service fournies par l'écosystème déjà présent.

3. De faire beaucoup de processing io-bound ? Python s'en sort aussi très bien, en particulier avec les apports des modes asynchrones des dernières versions.

4. De faire beaucoup de processing cpu-bound ? Clairement, Python n'est pas le meilleur candidat mais c'est quand même assez rare d'avoir des jobs cpu-bound pour lesquels il n'existe pas d'implémentation native.

5. De faire une interface graphique réactive ? Je fais régulièrement du Python avec PyQt et mes interfaces sont très réactives. Par exemple, j'ai utilisé récemment une vue sur des tableaux de plusieurs dizaines de milliers d'items sans problème visible.

6. De fournir un produit fonctionnel à un client à un coût moindre ? Python, avec sa rapidité de développement et l'immense bibliothèque de package disponible est certainement un candidat intéressant à considérer.

La soi-disant lenteur de Python est un vieux mythe qui continue de planer, déconnecté des réalités. Python est moins rapide que d'autres langages pour certaines tâches très précises, mais pour la majorité des programmes qui sont écrits, il est tout à fait suffisant.

Petite anecdote, j'ai participé à la "battle dev" ( https://battledev.blogdumoderateur.com/ ) sous le nom de ma boite et certains collègues habitués au C/C++ ont été choqués qu'on puisse résoudre la plupart des problèmes en Python, alors même qu'ils nécessitaient pas mal de calcul et de parcours de structures de données.

Je suis super d'accord. J'évite à tout prix de me reposer sur le typage dynamique en Python et ne l'utilise qu'en de très rares exceptions. Par contre, quand tu en as besoin, t'es content quand ça fasse partie du langage !

Dans ma vie de développeur C et C++, je suis régulièrement confronté au fait que les entiers soient un type "faible", c'est à dire sans limite précise.

Typiquement, j'ai un offset dans un tableau de taille fixe, mais il est représenté par un unsigned int (et encore, c'est quand je fais propre, le reste du temps, c'est un signed int). Et il peut circuler d'une fonction à une autre sous forme d'entier non signé, perdant complètement la notion de limite intrinsèque pour laquelle il a été défini. Le buffer overflow nous tend les bras et le compilateur ne peut rien faire pour le prévenir, c'est dans la définition du langage.

Beaucoup de bugs découlent de cette absence de typage, et les langages C/C++/Java ne font rien pour y remédier. Elle se retrouve sous plein de variantes : les Enum qui sont gérés comme des int par le compilateur, une structure définie avec des types ouverts (int, float, std::string), alors qu'en fait, seul un petit nombre de valeur sont autorisés pour ces champs, etc etc.

J'ai entendu dire que le bon langage pour tenir compte de ce genre de contrainte s'appelle Ada. J'ai encore jamais pris le temps ni l'énergie de m'y mettre, mais je suis persuadé que si je dois écrire un programme "sur", c'est vers lui que le me tournerai.

Quand on me dit que le C++ est typé, c'est vrai mais je me sens toujours pas en sécurité quand je l'utilise. Les buffers overflow et les déréferencements de pointeurs ont encore une longue vie devant eux.

Jusqu'à récemment, j'avais aussi la sensation de prendre des risques à coder un gros projet en Python. Depuis l'arrivée de Mypy et du typage dynamique, je suis plus tranquille. Je n'ai pas encore la sureté d'un langage compilé mais je trouve que le compromis "sureté / rapidité de développement / facilité de test" est très correct.

Quand je retourne au C et C++, je perds beaucoup sur les deux derniers points, et de mon point de vue, je ne gagne pas assez en sureté.

Je génère systématiquement des exécutables quand je livre des outils écrits en Python. En effet, sinon, la tambouille d'installation est trop rebutante. Py2exe, Py2app et Pyinstaller sont tes amis.

Il y a tout un tas de test que tu fais en python qui sont simplement inutiles en C++ du fait du typage statique de C++.

Ca, c'est du troll pur non ?

J'ai beau réfléchir, sur 15 ans de Python, les fois où j'ai du faire un test de typing pur en Python doivent se compter sur les doigts d'une main. Par contre, je profite régulièrement de la souplesse du typage de Python dans mes fonctions pour faire des trucs assez complexes qui, à faire en C++, demanderaient soit une classe dédiée, soit des template, soit d'être un expert C++18, soit les trois en même temps. Il y a beaucoup moins de boilerplate en Python.

Et mes tests Python sont souvent bien plus poussés que ceux que j'écris en C++ pour des fonctionnalités équivalentes, et ce pour plusieurs raisons:

• Python dispose d'un écosystème très étendu, permettant d'avoir pas mal de fonctionnalités déjà testées dans des lib externes, ce qui me permet de me concentrer sur des parties de mon code plus sensibles.
• En jouant sur les Mock et les propriétés dynamiques de Python, il est plus facile d'aller tester du code en profondeur.
• comme c'est plus rapide d'écrire du code en Python, l'écriture du code de test est aussi plus rapide, et à budget temps constant, je peux écrire plus de test, ou des tests qui vont plus en profondeur.

Il existe aussi des outils pour t'aider à améliorer ton code (il te propose même de patcher ton code directement).

Ca tombe bien, Python aussi. Ca va du simple Linter à MyPy ou PyCharm qui te permet de vérifier la cohérence des types utilisés dans ton projet (à peu près comme un compilo C++). D'ailleurs, il y a un français qui a fait une super conférence à ce sujet au PyData Paris 2018: https://www.youtube.com/watch?v=URP2e7hEUFw&list=PLzjFI0G5nSsry3cm_k1tPOi9SRaAXsZAt&index=6 (disclaimer: c'est moi qui présente).

Bah, ici, on est bloqué à Visual Studio 2011 en terme de licences. Alors du C++ moderne … je suis pas prêt d'en faire :-).

Par contre, ils sont un peu plus ouverts sur le Python bien que la version majoritairement déployée soit la version … 3.1 . Oui oui, le truc plus maintenu depuis 2012.