Discussion :

[Sve@r]

Alors que pour python, il suffit d'appeler la méthode qui est directement disponible. Il sera très facile pour un débutant, même s'il est adulte et consentant, de se tromper et d'appeler une méthode commençant par un underscore.

Déjà les méthodes (ou attributs) avec un underscore sont rares. Les méthodes privées sont mises avec deux underscores et celles-là pour les trouver et les appeler il ne faut ni être débutant ni se tromper.
Je me sers de méthodes (ou attributs) avec un underscore dans mes objets internes mais uniquement quand l'objet X (interne) a besoin de toucher l'objet Y (interne). Sinon c'est deux underscores pour les trucs qui restent dans l'objet.

Ensuite ben ce n'est pas parce qu'on a possibilité (en se trompant) de taper dans un truc auquel on n'a pas le droit que le principe est mauvais. Regarde le C par exemple. Sa philosophie principale c'est "pour aller le plus vite possible il ne vérifie rien, le programmeur doit savoir ce qu'il fait". De fait, on peut très bien définir un tab[10] et taper dans tab[11]. Le compilateur ne te dira absolument rien et même dans 98% des cas ça fonctionnera. Et comme les indices vont de 0 à 9, généralement le débutant commet l'erreur de taper dans tab[10]. Cela ne change pourtant pas la vision de ceux qui aiment ce langage pour ses qualités de vitesse.
Accessoirement en plus de leur rareté, les méthodes avec un underscore sont souvent cachées de la doc. Donc pour taper dedans même en se trompant... Et puis se tromper ben c'est se tromper quoi. Je ne vais pas aller te dire "ouais delphi c'est nul parce qu'on peut diviser par 0 en se trompant"...
Aucun langage de programmation n'est parfait, il n'existe même pas un langage meilleur que d'autres (Herbert Mayer). Python a fait des choix, ces choix entrainent des avantages mais aussi des inconvénients, on en est conscients. Ensuite on fait avec...

Tu vas me dire que c'est marqué dans tout les bons tutoriels. Mais pour en avoir parcouru un certain nombre, je peux t'affirmer que beaucoup n'en parlent pas.

Le mien en parle (il est en ce moment en train d'être évalué dans une section privée de ce forum mais les sondages semblent bons pour sa publication prochaine )

[wiztricks]

Tu vas me dire que c'est marqué dans tout les bons tutoriels. Mais pour en avoir parcouru un certain nombre, je peux t'affirmer que beaucoup n'en parlent pas.

Le mien en parle (il est en ce moment en train d'être évalué dans une section privée de ce forum mais les sondages semblent bons pour sa publication prochaine )

Ce dont on parle dans un tuto. dépendra du public visé et du niveau qu'on espère acquis en sortie.

Pour le programmeur "chevronné", le tuto de base est celui qui vient avec Python et il parle des attributs privés ici.

Si on s'intéresse au "style" des programmes Python, on essaiera de suivre les recommandations de la PEP8

- W

[popo]

Dans une voiture, il y a un mécanisme pour que les essuie-glace fassent des aller retour. Ce mécanisme n'est pas accessible parce que les fabricants estiment à juste titre que le conducteur n'a pas à s'en soucier, ce serait même dangereux s'il devait s'en soucier.

La division par 0 est une abberation mathématique.
Si tu connais un langage de programmation qui l'accepte je serais curieux de l'essayer.

Le C est un langage de bas niveau.
Autrement dit, il réservé à quelqu'un qui maîtrise des concepts avancés dont beaucoup de développeurs professionnels sur des langages de haut niveau (python ou autres) n'ont même pas conscience.

Je ne suis PAS en train de dire "python, c'est de la merde" comme tu sembles le suggérer. Effectivement, chaque langage a ses forces et ses faiblesses. Ce que je dis c'est que le concept de POO appliqué à python est déconcertant voire perturbant.
Quand tu lis un tutoriel théorique sur la POO et que tu t'aperçois que ce qu'il raconte n'est pas vrai quand essaie avec python, tu te dis que ce tutoriel est tout pourri. Tu en cherches donc un autre, il te dit la même chose. Et au bout d'un moment quand tu t'aperçois que TOUS disent la même chose, tu recherche des choses plus précises en associant par exemple le terme "python" avec le terme "protected". Et la réponse qui ressort le plus souvent ressemble à "ce ne sont pas les droïdes que vous recherchez..." ou bien ressemble à "on peut laisser la porte grande ouverte et même déposer une liasse de billet bien en évidence sur le sol puisque les gens sont disciplinés et savent que, puisque que la porte est rouge, ils doivent passer leur chemin".

Bref, c'est un concept que je trouve étrange.
J'irai même jusqu'à dire "paradoxal " puisque d'un côté, on te vend la souplesse et l'ouverture mais de l'autre on te dit de ne surtout pas déroger aux conventions établies.

Puisque c'est la norme, je vais m'y conformer mais ça reste bizarre.

[Sve@r]

La division par 0 est une abberation mathématique.
Si tu connais un langage de programmation qui l'accepte je serais curieux de l'essayer.

Oui c'est vrai que l'exemple était mauvais. Je ne connais malheureusement pas Delphi pour trouver un exemple parlant. Mais Delphi est-il exempt de reproches sur ce sujet?

ou bien ressemble à "on peut laisser la porte grande ouverte et même déposer une liasse de billet bien en évidence sur le sol puisque les gens sont disciplinés et savent que, puisque que la porte est rouge, ils doivent passer leur chemin"

Euh... la liasse de billets... je dirais plutôt "il n'est pas besoin de fermer la porte à clef, de toute façon c'est une porte de maison japonaise en papier et on peut la traverser sans souci ; sauf que puisque les gens sont disciplinés ils ne l'ouvriront pas mais s'ils l'ouvrent et qu'il y a un trou derrière c'est tant pis pour eux"

Bref, c'est un concept que je trouve étrange. J'irai même jusqu'à dire "paradoxal " puisque d'un côté, on te vend la souplesse et l'ouverture mais de l'autre on te dit de ne surtout pas déroger aux conventions établies.

Euh... On te venddonne (Python est 100% gratuit) de la souplesse mais la souplesse de ton code s'arrête à la souplesse des autres. Et puis tu as le droit de taper dans les méthodes protected, cela ne t'es pas interdit. Simplement ces méthodes ne sont pas présumées utilisables par le public donc l'auteur n'aura aucun scrupule à les faire changer si nécessaire lors des évolutions de son code. Si ensuite sa librairie v2 ne fonctionne plus chez-toi parce que la méthode _truc() de sa lib v1 que tu utilisais de partout a disparu, tant pis pour toi. Tu ne pourras pas légitimement lui en vouloir. C'est surtout pour te protéger toi qu'on te demande poliment de ne pas utiliser ces méthodes et qu'on t'offre généralement à la place des méthodes de substitution ou d'encapsulation. En fait les conventions sont là pour que tous les codes puissent agréablement se connecter les uns aux autres sans crainte d'une perte suite à évolution. C'est comme ma prose. J'essaye de respecter la grammaire française de mon mieux mais je pourrais dire que puisque l'alphabet est souple, rien ne m'y force. Sauf qu'il y a des conventions établies pour que tu la lises agréablement sans te faire saigner les yeux.

En fait (je vais essayer d'être plus simple) oui Python ne respecte pas ce principe. Mais que peut-on y faire? Je ne suis pas concepteur (ou travaillant avec les concepteurs) de Python donc je ne sais pas si on aurait pu lui obliger à les respecter. wiztricks (qui est une référence ici) dit que non donc j'ai plutôt tendance à le croire. Et comme Python reste un langage interprété, je suis alors d'accord avec le fait que lui faire mettre des barrières (ce qui prend du temps) facilement contournables c'est alors inutile.
Donc les concepteurs, qui sont probablements tout aussi conscients que toi de cette impossibilité, ont tenté d'y mettre des solutions palliatives en disant "le respect de ce principe passera par le bon vouloir des utilisateurs parce qu'il n'y a pas d'autre solution" mais oui, ces solutions palliatives ne sont que palliatives. Ensuite tu arrives, tu t'interroges sur la façon de faire et donc on t'explique la façon qu'ont eu les concepteurs de répondre de leur mieux à ton besoin mais encore une fois leur façon de faire n'est que palliative et fatalement si tu t'acharnes à vouloir creuser on arrive au final à une impasse. Ok Python ne peut pas faire du private et/ou du protected c'est admis. Et donc?
Ensuite comme j'aime ce langage moi ça ne me dérange pas. Après que peut-on dire de plus? Si tu veux continuer avec Python tu es alors obligé de faire avec. Ok tu pourras dire "il ne respecte pas il ne respecte pas" mais bon, il n'en reste pas moins incontournable que tu restes obligé de faire avec. Tant pis, le petit est né comme ça mais je l'aime quand-même.

[Pyramidev]

La division par 0 est une abberation mathématique.
Si tu connais un langage de programmation qui l'accepte je serais curieux de l'essayer.

Pony : https://tutorial.ponylang.io/express...ger-arithmetic

[wiztricks]

Dans une voiture, il y a un mécanisme pour que les essuie-glace fassent des aller retour. Ce mécanisme n'est pas accessible parce que les fabricants estiment à juste titre que le conducteur n'a pas à s'en soucier, ce serait même dangereux s'il devait s'en soucier.

Le programmeur est lui même fabriquant et coopère indirectement avec les créateurs des bibliothèques qu'il utilise. On peut bien mettre des barrières pour le protéger contre les bêtises qu'il pourrait envisager de faire... et discuter de la qualités des barrières proposées par différents langages.

Mais partons du principe que le programmeur est quelqu'un d'intelligent (ce que fait Python), pourquoi j'ai besoin d'avoir des attributs privés ou protégés et en quoi cela gène de ne pas avoir une barrière explicite?

La barrière traite de ce qu'il se passe côté accès aux attributs d'une classe parente par une sous/classe (au moins pour C++, avec Java "protected" est étendu à l'espace de nommage).

On est dans les fonctionnalités de l'héritage... et de vieilles discussions dans les églises de la POO qui privilégient la construction d'application via héritage ou composition.

Si on construit une application par héritage, on a intérêt à limiter l'accès aux différents attributs dont on va hériter, soit pour des questions de propriété intellectuelle, soit pour des questions de maintenance (au sens ou private/protected vs. public couvre aussi des détails de l'implémentation dont on n'a pas envie que l'utilisateur dépendent si on doit "bouger" les algos, le code,... on garantit les interfaces publiques ou on se limite à documenter les éventuels changements dans...).

Les promoteurs des constructions par composition ont sortis pattern de conception et autres design patterns montrant les avantages de leur techniques... et aujourd'hui on peut dire qu'ils ont gagné au sens ou l'héritage est utilisé de façon bien plus limitée/raisonnée.

Si on reste raisonnable côté héritage, on n'a plus trop de raisons techniques (au sens ça ne va pas gêner le développeur) d'un héritage avec des barrières "fortes".

Si on voit la chose comme contrat entre l'utilisateur d'une bibliothèque et son réalisateur permettant de dire, çà c'est privé ou protégé et si tu te reposes dessus, pas la peine de râler si çà n'existe plus (ou si çà change) dans une version future...
Alors moi, j'aime bien le côté Python de ne se baser que sur des conventions (ou presque côté private, il faut faire un peu plus pour garantir la portée de l'attribut).

Et dans la pratique on n'a pas besoin de plus sauf à pouvoir cocher des cases dans des comparatifs des fonctionnalités entre différents langages (mais on ne code pas avec ces trucs là!).

- W

[popo]

Pony : https://tutorial.ponylang.io/express...ger-arithmetic

Excellente trouvaille.
A première vu, Pony semble être être une surcouche à c++ (un peu comme fait TypeScript avec JavaScript à la différence que Pony est compilé).
Mais bon, on s'éloigne du sujet.

Dans une voiture, il y a un mécanisme pour que les essuie-glace fassent des aller retour. Ce mécanisme n'est pas accessible parce que les fabricants estiment à juste titre que le conducteur n'a pas à s'en soucier, ce serait même dangereux s'il devait s'en soucier.

Le programmeur est lui même fabriquant et coopère indirectement avec les créateurs des bibliothèques qu'il utilise. On peut bien mettre des barrières pour le protéger contre les bêtises qu'il pourrait envisager de faire... et discuter de la qualités des barrières proposées par différents langages.

Pas d'accord, le conducteur n'est pas un fabricant.
Et même en admettant qu'il le soit, ce n'est pas parce qu'il connait la mécanique interne qu'il peut y accéder lorsqu'il conduit.

Mais partons du principe que le programmeur est quelqu'un d'intelligent (ce que fait Python), pourquoi j'ai besoin d'avoir des attributs privés ou protégés et en quoi cela gène de ne pas avoir une barrière explicite?

Tout simplement parce que quand je tape un point dans mon éditeur, je trouve gênant de voir apparaître 15 méthodes commençant par un underscore avant de voir les méthodes que je peux effectivement utiliser. Et si je n'ai pas à m'en soucier alors ne pourquoi me mes proposer ?

Mais également parce que l'erreur est humaine et que même un programmeur confirmé peut prévoir une méthode interne et oublier l'underscore.
Et moi, en tant que programmeur discipliné, je vais voir que cette méthode sans underscore et l'utiliser en toute confiance.
Qu'est-ce qui va se passer lorsqu'il va se rendre compte de son erreur et placer un underscore pour respecter la convention ?
Je vais me retrouver avec un bug et je risque de passer à coté.
Et du coup c'est l'utilisateur du programme qui va le remonter plusieurs mois après.
Je vais passer du temps pour analyser les changements de code pour m'apercevoir que la méthode en question fait partie d'une portion qui n'a pas bougé.
Bref, je vais perdre un temps fou alors que si dès le départ cette même méthode m'avait été cachée (parce que déclarée protected), ça ne serait jamais arrivé.
Tu ne vois toujours pas pourquoi je trouve ça gênant ?

Si on voit la chose comme contrat entre l'utilisateur d'une bibliothèque et son réalisateur permettant de dire, çà c'est privé ou protégé et si tu te reposes dessus, pas la peine de râler si çà n'existe plus (ou si çà change) dans une version future...

En programmation par contrat, on ne dit pas "ça c'est protégé" et encore moins "ça c'est privé", on te dit "voila mon contrat, voila ce que tu peux utiliser".

[wiztricks]

Tout simplement parce que quand je tape un point dans mon éditeur, je trouve gênant de voir apparaître 15 méthodes commençant par un underscore avant de voir les méthodes que je peux effectivement utiliser. Et si je n'ai pas à m'en soucier alors ne pourquoi me mes proposer ?

Si votre éditeur ne filtre pas les variables qui commencent pas '_', il faut aller demander ça à ceux qui ont développé l'éditeur. Côté Python, il y a la méthode __dir__ pour remonter les attributs de son choix.

Mais également parce que l'erreur est humaine et que même un programmeur confirmé peut prévoir une méthode interne et oublier l'underscore.
Et moi, en tant que programmeur discipliné, je vais voir que cette méthode sans underscore et l'utiliser en toute confiance.
Qu'est-ce qui va se passer lorsqu'il va se rendre compte de son erreur et placer un underscore pour respecter la convention ?

Il écrit un paragraphe dans le release notes de la nouvelle version puisqu'il modifie l'interface publique. Et il fera pareil s'il a oublié de mettre private ou protected...

Je vais me retrouver avec un bug et je risque de passer à coté.
Et du coup c'est l'utilisateur du programme qui va le remonter plusieurs mois après.

Ah ben si on installe une nouvelle version sans lire le release notes, c'est ce qu'il se passe (et ce n'est pas spécifique à Python).

Tu ne vois toujours pas pourquoi je trouve ça gênant ?

En programmation par contrat, on ne dit pas "ça c'est protégé" et encore moins "ça c'est privé", on te dit "voila mon contrat, voila ce que tu peux utiliser".

On fait exactement la même chose avec Python... mais vous tiquez sur la forme préférant des keywords (que l'utilisateur n'est pas supposé voir) à des annotations (qu'il respecte ou pas).
Je respecte vos préférences mais je ne les partage pas.

Et même en admettant qu'il le soit, ce n'est pas parce qu'il connait la mécanique interne qu'il peut y accéder lorsqu'il conduit.

S'il y a un problème, on arrête la voiture pour ouvrir le capot... après avoir fait un premier diagnostic à l'oreille et récupéré sa trousse à outils. Pour les codes, en cas de "bug" (programme) on ne va pas modifier en live la version utilisée par les utilisateurs (on évite en arrêtant l'application avant... comme pour la voiture).

note: à mes débuts, avec le privilège wheel l'OS permettait de lancer le débugueur système "live"... C'était cool pour faire des blagues mais si on se plante la machine crashe (et les utilisateurs ne sont pas contents).

- W

[Sve@r]

Et même en admettant qu'il le soit, ce n'est pas parce qu'il connait la mécanique interne qu'il peut y accéder lorsqu'il conduit.

Le souci avec les analogies, c'est que le parallèle avec le sujet initial ne dure pas longtemps. Et donc si l'action X est/n'est pas possible dans l'analogie, malheureusement cela n'apporte alors plus vraiment de pertinence dans le discours ayant trait au sujet initial. Ainsi "conduire" et "coder" ce n'est pas pareil. Dans le premier cas on est utilisateur d'un produit fini (ie la voiture), dans le second cas on est concepteur d'un produit futur. Ok on est aussi l'utilisateur de produits finis faits par d'autres (ie les librairies) mais c'est justement là le souci de l'analogie: poussée trop loin elle ne veut plus rien dire car une librairie (un code, des outils utilisables) ce n'est pas une voiture (un capot fermé qu'on ne va surtout pas ouvrir).

Tout simplement parce que quand je tape un point dans mon éditeur, je trouve gênant de voir apparaître 15 méthodes commençant par un underscore avant de voir les méthodes que je peux effectivement utiliser. Et si je n'ai pas à m'en soucier alors ne pourquoi me mes proposer ?

Ah là c'est intéressant Je n'y avais en effet pas songé, étant de mon côté développeur mode "vi", donc sans éditeur intelligent ni autre (enfin je ne suis pas resté à l'âge de pierre, je suis quand-même passé à "gvim" ).
Mes seules façons de connaitre les propriétés d'un outil sont dir(outil), help(outil) ou tout simplement la doc.
Sauf que là tu décris un souci lié à ton éditeur, pas un souci lié aux conventions dont nous parlons (j'espère pour toi avec toujours autant de plaisir que pour moi ). Si le concepteur dudit éditeur ne respecte pas (que ce soit volontairement ou pas) les conventions ce n'est pas la faute du langage qui a établi et expliqué ces conventions.

Mais également parce que l'erreur est humaine et que même un programmeur confirmé peut prévoir une méthode interne et oublier l'underscore.
Et moi, en tant que programmeur discipliné, je vais voir que cette méthode sans underscore et l'utiliser en toute confiance.
Qu'est-ce qui va se passer lorsqu'il va se rendre compte de son erreur et placer un underscore pour respecter la convention ?
Je vais me retrouver avec un bug et je risque de passer à coté.
Et du coup c'est l'utilisateur du programme qui va le remonter plusieurs mois après.
Je vais passer du temps pour analyser les changements de code pour m'apercevoir que la méthode en question fait partie d'une portion qui n'a pas bougé.
Bref, je vais perdre un temps fou alors que si dès le départ cette même méthode m'avait été cachée (parce que déclarée protected), ça ne serait jamais arrivé.
Tu ne vois toujours pas pourquoi je trouve ça gênant ?

Oui je vois. Là tes arguments sont pertinents. Ok ils sont basés sur une erreur préalable du concepteur de la librairie que tu utilises ; donc je vais m'arrêter brièvement sur ce point (le seul point en réalité qui de ton discours qui permette de l'attaquer). Donc tu dis que le programmeur de la librairie toto a "oublié" que sa méthode xxx() était interne et toi qui utilises cette librairie tu accèdes à "xxx" en toute confiance. Bon déjà un concepteur de librairie qu'il veut offrir à la communauté c'est pas vraiment un débutant (il faut qu'il soit costaud pour créer un outil susceptible d'être utilisé par d'autres) et penser qu'il puisse faire cette erreur à son niveau... mais ok, admettons, personne n'est parfait. Donc de là tu as parfaitement raison, cette méthode xxx() est effectivement publique et tu es en droit absolu de l'utiliser !!!

Voici alors comment je pense que cela va probablement se passer: le développeur se rendant compte que "xxx()" n'aurait pas dû (ou n'avait pas besoin) d'être publique se dépèche de la rendre privée dans sa v2 et inscrit dans son changeLog cette modification, indiquant alors aux utilisateurs que s'ils veulent utiliser sa libToto_v2 ils devront alors trouver une solution pour ne plus utiliser xxx(). Il se peut même qu'il indique comment s'en passer. Et toi effectivement si tu veux continuer à utiliser libToto_v2 alors tu devras faire la migration de ton code. Mais il ne changera certainement pas "xxx()" pour "__xxx()" dans son coin sans prévenir parce que ça c'est un coup à effectivement tuer sa lib.

En plus ce cas se présente en permanence (sauf que ce n'est pas une erreur). Régulièrement des outils sont mis à jour et ceux qui veulent continuer à les utiliser doivent alors se sortir les doigts. Je m'y suis récemment frotté quand les QStrings de PyQt4 ont disparu au profit des str Python sous PyQt5. Et avec les QString ont disparu aussi la méthode QString.fromutf8() qui servait à convertir un texte en utf8. Plus les QStringList (rempplacées alors par des listes ou tuples). La méthode QObject.connect() a totalement disparu. Et cette méthode n'était pas une erreur, elle était vraiment publique et en plus d'une importance capitale car elle servait à connecter les objets, connection qui est la base de Qt. Mais les concepteurs l'ont faite évoluer. Et moi j'ai dû me taper des centaines de codes pour chercher toutes mes QString, toutes mes QString.fromUtf8, toutes mes QStringList, mes QObject.connect, et les remplacer par leur successeur (heureusement gvim n'est pas dépourvu de ressources pour aider à ce travail). Sans compter en plus les librairies qui disparaissent !!!
Donc oui c'est gênant je suis d'accord. Mais c'est le lot de ceux qui ont choisi Python parce que cette gêne ne dépasse pas (pas encore) les avantages que ceux qui aiment ce langage en retirent, avantages principaux en termes de rapidité de développement.

[Pyramidev]

Mais également parce que l'erreur est humaine et que même un programmeur confirmé peut prévoir une méthode interne et oublier l'underscore.

Un point intéressant à remarquer est que le risque que le créateur d'une méthode supposée être privée oublie de la déclarer comme privée et la laisse en public existe dans tous les langages dans lesquels les fonctions sont publiques par défaut, y compris certains langages compilés comme Scala.

En ce qui me concerne, je crée plus de fonctions privées que de fonctions publiques, donc ça m'arrange quand un langage de programmation considère que tout est privé par défaut. Par exemple, c'est le cas de Rust où il faut utiliser le mot-clef pub pour qu'un élément soit public.

À part ça, en Python, si on utilise Pylint et si on appelle une fonction non-publique là où on ne devrait pas l'appeler, on a un avertissement protected-access (W0212). Pour les projets en Python, il est important de faire appel à des linters. Je conseille d'appeler Pylint depuis la CI.

[Sve@r]

En ce qui me concerne, je crée plus de fonctions privées que de fonctions publiques, donc ça m'arrange quand un langage de programmation considère que tout est privé par défaut. Par exemple, c'est le cas de Rust où il faut utiliser le mot-clef pub pour qu'un élément soit public.

C'est aussi le cas en C++ où les membres et méthodes d'une classe sont privés par défaut et il faut là aussi spécifier explicitement ce qu'on veut rendre public. J'aime bien cette notion où tout est fermé par défaut et on n'ouvre de façon explicite que ce que l'on décide d'ouvrir. C'est le cas de l'OS Unix (et ses clones dont Linux fait partie). Dans cet OS tous les fichiers sont verrouillés par défaut et seuls sont rendus modifiables ceux que l'on désire explicitement rendre modifiables. C'est un point important dans ce qui fait sa fiabilité et sa sécurité et effectivement si Python avait adhéré à cette philosophie personnellement ça ne m'aurait pas déplu. Tant pis...

[popo]

wiztricks, Sve@r,
Encore faut-il que la release note le mentionne.
Si le concepteur de la librairie s'en aperçois alors qu'il est concentré sur autre chose, il peut aisément oublier cette modification lorsqu'il écrira la release note.

J'ai justement rencontré un cas concret avec sqlalchemy (dont wiztricks m'a vanté les mérites dans un autre post) et en particulier sur la routine "mapper".
Après deux tutoriels disant à peu près la même chose, c'est à dire déclarant une Table et utilisant "mapper" pour faire correspondre un objet métier aux colonnes de la table, je fais l'essai sur un cas concret mais un peu plus complexe que dans les tutoriels.
Comme on pouvait s'y attendre, je rencontre un cas non abordé dans ces tutoriels.
Du coup, je vais rechercher dans la documentation officiel où j'apprend (en tombant dessus par hasard) que depuis la version 1.4 la fonction "mapper" est dépréciée.
Il faut créer un objet de type Registry et appeler registry.map_imperatively().
Sauf que ni dans la release note, ni dans le changelog de la 1.4.0 ce n'est mentionné.
Je n'ai pas eu le courage de regarder dans les release notes et les changelog des 1.4.1 à 1.4.27 mais j'estime qu'une dépréciation n'a pas sa place dans une version mineure.
Quand on écrit une librairie, on ne s'amuse pas à changer le contrat.
Et encore moins si c'est dans un langage interprété.

Mais quoi qu'il en soit, si a chaque fois qu'on veut changer la version d'une librairie, il faut se taper les release note et le changelog de chaque version mineure intermédiaire (et celles de chaque librairie dont elle dépend si on a le malheur d'en utiliser une partie aussi), et modifier des centaines des lignes de codes parce que le concepteur de la librairie a décidé de changer le contrat, on ne fait plus que ça.

Et admettons que je prenne le temps de le faire quand même, rien ne me garantit que tous mes collègues fassent preuve de la même rigueur.
Si vous convient, tant mieux pour vous.
Mais moi je n'adhère pas.

C'est pour ça que je préfère largement que le système soit suffisamment robuste pour empêcher certaines dérives, plutôt que de compter sur la bonne volonté des gens.
Quand je vous lis j'ai l'impression que vous travaillez systématiquement tout seuls et sur des projets one shot.

En programmation par contrat, on ne dit pas "ça c'est protégé" et encore moins "ça c'est privé", on te dit "voila mon contrat, voila ce que tu peux utiliser".

On fait exactement la même chose avec Python... mais vous tiquez sur la forme préférant des keywords (que l'utilisateur n'est pas supposé voir) à des annotations (qu'il respecte ou pas)

Ton affirmation est en contradiction totale avec tout ce que tu m'a dit jusque là.
Tu m'as dis et répété que si je vois des méthodes commençant par l'underscore, c'est à moi d'être assez discipliné pour ne pas les appeler.
En programmation par contrat, je ne ne suis même pas sensé avoir conscience de leur existence.
Le contrat est justement fait pour masquer le détail, il ne présente que ce qui est public.

Un point intéressant à remarquer est que le risque que le créateur d'une méthode supposée être privée oublie de la déclarer comme privée et la laisse en public existe dans tous les langages dans lesquels les fonctions sont publiques par défaut, y compris certains langages compilés comme Scala

Sauf qu'il est plus facile pour l'œil humain de voir qu'il manque le mot clé "protected" que de voir qu'il manque un underscore.
On retrouve le même problème en .Net où pour raccourcir le code et éviter de tester si un objet est null (c'est le None de .Net), on place un point d'interrogation devant le point.
Sauf que depuis, certains programmeurs pas très rigoureux placent systématiquement ce point d'interrogation pour ne pas avoir à se poser la question.

[wiztricks]

Comme on pouvait s'y attendre, je rencontre un cas non abordé dans ces tutoriels. Du coup, je vais rechercher dans la documentation officiel où j'apprend (en tombant dessus par hasard) que depuis la version 1.4 la fonction "mapper" est dépréciée.

Les bons tutos mentionnent la version sur laquelle les exemples sont construits.
Sorti de ce cadre, on se retrouve dans une logique de migration/mise à jour des exemples comme on le ferait avec n'importe quel autre code.

Et effectivement, les développeurs sont des humains qui oublient parfois de... et les utilisateurs de bibliothèques externes sont aussi des humains qui ont appris à se reposer prudemment sur le travail des autres... Et développer des stratégies ad hoc par rapport aux risques qu'ils ne veulent pas prendre et aux coûts (on évalue çà en bénéfices/risques comme la santé publique) de la mise en place de contre mesures.

Une stratégie peu coûteuse sera des rester en N-2: s'il y a des problèmes difficiles au passage en N-1, on espère qu'ils ont déjà été rencontrés par d'autres et qu'on s'en sortira vite en cherchant un peu.

Plus coûteux seront le développement d'une batterie de tests de non-régression et une plateforme de tests continus. Dans ce cas, on pourra estampiller "supporté avec la version N" plus tôt (et contribué à documenter les problèmes solutions dont pourront profiter ceux qui n'ont pas ces moyens/exigences).

Les erreurs humaines se traitent avec des outils qui permettent de s'assurer de la qualité de ce qui est produit (et qu'on ait des keywords public/private ou juste des conventions ne change en rien les faiblesses humaines, juste les outils et les précautions à prendre).

Mais quoi qu'il en soit, si a chaque fois qu'on veut changer la version d'une librairie, il faut se taper les release note et le changelog de chaque version mineure intermédiaire (et celles de chaque librairie dont elle dépend si on a le malheur d'en utiliser une partie aussi), et modifier des centaines des lignes de codes parce que le concepteur de la librairie a décidé de changer le contrat, on ne fait plus que ça.

C'est juste le boulot des programmeurs... et c'est pas facile de choisir les bons outils (car ça va de la conception aux tests) et souvent lourd à mettre en place. Sur ce site vous avez toute une rubrique consacrée à ces sujets: Application Lifecycle Management.

C'est pour ça que je préfère largement que le système soit suffisamment robuste pour empêcher certaines dérives, plutôt que de compter sur la bonne volonté des gens.

C'est votre point de vue et il se respecte. Je m'attache seulement à vous souligner que les fonctionnalités du langage sont une contrainte parmi d'autres. Bien sûr, si vous n'avez pas eu la chance de faire du développement de logiciels de qualité militaire et de voir comment on peut organiser tout çà (même lorsqu'on développe en assembleur), vous vous posez des questions qui me semblent "bizarre".

- W

[Arioch]

Mais quoi qu'il en soit, si a chaque fois qu'on veut changer la version d'une librairie, il faut se taper les release note et le changelog de chaque version mineure intermédiaire (et celles de chaque librairie dont elle dépend si on a le malheur d'en utiliser une partie aussi), et modifier des centaines des lignes de codes parce que le concepteur de la librairie a décidé de changer le contrat, on ne fait plus que ça.

Dans le cadre professionnel dans lequel j'évolue, nous travaillons autant que faire se peut en TDD. Donc nous écrivons les tests avant les méthodes de classes au fur et à mesure que nous avançons dans le projet.

En environnement virtuel, nous utilisons venv et installons nos libraires. Un pip freeze après installation de toutes les dépendances nous permet d'identifier les librairies additionnelles propres au programme et celles propres au développement et nous stockons ces freeze dans des fichiers distincts prod'/dévs.

Le retour de la commande pip freeze nous permet de connaître la dernière version en date de chaque librairie additionnelle.

Nous choisissons ensuite si nous conservons ce numéro de version ou non. Sous-entendu ici, si nous souhaitons "forcer" l'installation d'une version spécifique de module ou non.

Ensuite, les tests unitaires/fonctionnels/d'intégration nous permettent, à chaque nouvelle installation de notre programme en mode CI/CD de savoir s'il tourne toujours correctement (si les tests passent au vert) ou non.

Ainsi, nul besoin de se pencher sur les "what's new" d'une nouvelle version de librairie.

Je donne ici juste mon avis de développeur Python hein, pas taper si vous trouvez mes propos hors contexte.

[Sve@r]

Mais quoi qu'il en soit, si a chaque fois qu'on veut changer la version d'une librairie, il faut se taper les release note et le changelog de chaque version mineure intermédiaire (et celles de chaque librairie dont elle dépend si on a le malheur d'en utiliser une partie aussi), et modifier des centaines des lignes de codes parce que le concepteur de la librairie a décidé de changer le contrat, on ne fait plus que ça.

Effectivement. Quand on est passé de Python v2 à Python v3 ça a été un gros travail pour tout le monde (c'est d'ailleurs la raison qui a fait que la fin officielle de Python v2 a été repoussée de 2015 à 2020). De même Qt4 à Qt5 là aussi a été drastique (toutefois là c'est Qt C++ qui a évolué et les mainteneurs de sa version Python "PyQt" ont alors dû suivre). Mais bon tu remarqueras que c'étaient des versions majeures et non mineures

Si vous convient, tant mieux pour vous.
Mais moi je n'adhère pas.

Ok. Désolé de n'avoir pas pu te convaincre
Maintenant que peut-on y faire ? Et surtout que vas-tu faire toi vis à vis de Python ?

Quand je vous lis j'ai l'impression que vous travaillez systématiquement tout seuls et sur des projets one shot.

Pour ma part oui et non. Effectivement je suis seul sur mes projets mais je t'assure qu'ils ne sont pas one shot. Je fais un suivi de version très pointilleux. Quand j'ai porté de P2 vers P3 et de Qt4 vers Qt5 j'ai commencé par créer le dossier vierge "V+1", puis y copier tous mes sources du dossier "V" et ensuite seulement commencé à travailler. Et chaque fonction, chaque objet réécrit était alors testé.
Et ce n'est pas parce que je suis seul sur mes projets que je n'applique pas mes propres valeurs (qui sont proches des tiennes en plus !!!). Chaque fois que je crée un objet, je commence par tout mettre en privé. Et si plus tard je me rends compte qu'un autre objet (donc externe au premier) a besoin d'accéder à un truc du premier qui a été mis en privé, je commence alors à me demander si je dois le laisser en privé et lui rajouter un getter/setter ou alors le mettre public. Je ne dis pas que mes choix sont les meilleurs mais au-moins j'y réfléchis.

Sauf qu'il est plus facile pour l'œil humain de voir qu'il manque le mot clé "protected" que de voir qu'il manque un underscore.

Exact, je ne peux qu'être d'accord. Mais là encore je n'ai plus d'argument. Quand on fait intervenir l'humain on ne peut plus conclure quoi que ce soit. Je me souviens du film "Sully" qui relate l'accident qui a forcé le commandant de bord d'un boing à amerrir sur l'Hudson suite à une collision avec des oiseaux. A la fin de la commission d'enquête, toutes les simulations montrent que l'avion aurait pu revenir à La Guardia ou alors de dérouter sur une piste annexe. Là le héros prend la parole et dit "arrêtons ces conneries, toutes ces simulations partent du fait que le pilote était prévenu de la la collision et à l'extinction des moteurs que ça a entrainé. Nous nous ne nous y attendions pas et avons mis du temps à réagir. Vous voulez de l'humain, rajoutez de l'humain aux simulations" (qui en plus ont été tentées 18 fois en privé avant d'être enfin réussies). Ils rajoutent donc 37 secondes de latence entre la collision et la décision de se dérouter et là les simulations échouent. Quand on rajoute de l'humain, on ne peut plus conclure. Nous ne sommes pas des robots (malheureusement ou heureusement à toi de voir). On fait avec (en Python du moins, et là c'est heureusement moins grave qu'en avion... ). Et j'espère qu'on s'en sort. Désolé pour ton souci SQLAlchemy, moi aussi j'ai vu le post dont tu parles et j'ai été emballé et commence à m'y intéresser. Ton exemple me servira. Attention quand-même, ce n'est pas parce qu'un truc est "déprécié" qu'il en devient "interdit". Déprécié c'est une juste une étape qui dit "ce sera bientôt interdit mais ça ne l'est pas encore, vous avez le temps de changer ça"...

On retrouve le même problème en .Net où pour raccourcir le code et éviter de tester si un objet est null (c'est le None de .Net), on place un point d'interrogation devant le point.
Sauf que depuis, certains programmeurs pas très rigoureux placent systématiquement ce point d'interrogation pour ne pas avoir à se poser la question.

Ah là oui je peux répondre. Ce n'est pas parce que certains devs sont dégueux (flemmards, glandeurs, paresseux et toute une gamme de synonymes qui va avec) que leur façon de faire doit servir de référence. A mon avis ils le paieront tôt ou tard (ou, pire, d'autres paieront pour eux !!!)

[popo]

Les bons tutos mentionnent la version sur laquelle les exemples sont construits.
Sorti de ce cadre, on se retrouve dans une logique de migration/mise à jour des exemples comme on le ferait avec n'importe quel autre code.

Une librairie, c'est un contrat.
On ne change pas un contrat comme on change de chemise.

Et effectivement, les développeurs sont des humains qui oublient parfois de... et les utilisateurs de bibliothèques externes sont aussi des humains qui ont appris à se reposer prudemment sur le travail des autres... Et développer des stratégies ad hoc par rapport aux risques qu'ils ne veulent pas prendre et aux coûts (on évalue çà en bénéfices/risques comme la santé publique) de la mise en place de contre mesures.

Une stratégie peu coûteuse sera des rester en N-2: s'il y a des problèmes difficiles au passage en N-1, on espère qu'ils ont déjà été rencontrés par d'autres et qu'on s'en sortira vite en cherchant un peu.

Plus coûteux seront le développement d'une batterie de tests de non-régression et une plateforme de tests continus. Dans ce cas, on pourra estampiller "supporté avec la version N" plus tôt (et contribué à documenter les problèmes solutions dont pourront profiter ceux qui n'ont pas ces moyens/exigences).

Si tu en arrives à avoir besoin de faire des tests de non régression sur une librairie que tu n'a pas toi même développé, c'est que tu en as une confiance très limitée.
Donc considérer que le développeur "sais ce qu'il fait" a ses limites, et vous avez vous-même pu le constater.
Cela encore est contradiction totale avec tout le discours que vous m'avez sorti jusque là.

Les erreurs humaines se traitent avec des outils qui permettent de s'assurer de la qualité de ce qui est produit (et qu'on ait des keywords public/private ou juste des conventions ne change en rien les faiblesses humaines, juste les outils et les précautions à prendre).

C'est juste le boulot des programmeurs... et c'est pas facile de choisir les bons outils (car ça va de la conception aux tests) et souvent lourd à mettre en place. Sur ce site vous avez toute une rubrique consacrée à ces sujets: Application Lifecycle Management.

Ce genre d'outil n'est pas gratuit et s'il l'est on peut se poser des questions sur sa longévité, sur le suivi des évolutions du langage.
A la base, j'ai voulu regarder python parce qu'il semblait populaire et surtout gratuit.
S'il faut acheter tout un tas d'outil payant pour être serain, ça perd de son intérêt.

Bien sûr, si vous n'avez pas eu la chance de faire du développement de logiciels de qualité militaire et de voir comment on peut organiser tout çà (même lorsqu'on développe en assembleur), vous vous posez des questions qui me semblent "bizarre".

Mes questions vous semblent probablement bizarre parce que vous ne développez qu'avec python.
Arrêtez donc de me prendre pour un débutant.
Je suis passé par pas mal de langage durant ma carrière : C#, Delphi, Delphi.Net, Java, VB, VB.Net, PHP, ASP (qui sont tous des langages objets et certains sont même interprétés)
N'importe quel développeur sur ces langages s'étonnerai de voir le principe d'encapsulation totalement ignoré.
N'importe quel développeur sur ces langages s'étonnerai de constater que c'est le nom de la méthode qui en fait une méthode protégée.
N'importe quel développeur sur ces langages qui a déjà distribué des API ou des librairies serai choqué de constater qu'en python on se permet de changer un contrat comme on change de chemise.

Nous n'avons certainement pas la même notion d'un développement de qualité militaire.
Mais, je sais ce que c'est de développer pour des militaires et je peux vous assurer qu'ils sont moins souple que moi.

Au départ j'ai simplement dit que je trouvait étrange qu'un underscore signifie "protégé" et deux, "privé".
Et ne maîtrisant pas python, j'ai pris la peine de demander s'il n'y avait pas un moyen de rétablir le comportement auquel je suis habitué.
Vous m'avez dit "non". J'ai dit "OK, mais je trouve ça bizarre".
Cela aurait pu s'arrêter là, mais vous avez voulu continuer à débattre et à essayer de me convaincre que la philosophie de python, c'est génial.
Pas de problème en soit, je suis pour les échanges de points de vues.

Mais là, vous insinuez carrément que je ne suis qu'un débutant et que je ne sais pas faire du développement de qualité.
Au lieu d'essayer de vous rabaisser comme vous le faites avec moi je vais simplement vous donner un aperçu de ce que c'est de travailler avec des militaires.

Et je vais commencer par reprendre l'exemple de SqlAlchemy
Il est bourré de vulnérabilités :
https://nvd.nist.gov/vuln/detail/CVE-2019-7164
Exit direct.

Des méthodes sont dépréciées et ce n'est pas inscrit dans la sacro-sainte release note.
Erreur humaine de ne pas le noter.
Mais si en plus le concepteur ne prend pas la peine de mettre le @deprecated, on ne va pas se gêner pour aller lui souffler dans les bronches.
Oui, car en règle générale, on finance les librairies utilisées pour qu'elles restent maintenues.

De manière plus générale :
On passe des contrat avec les développeurs de librairies et je peux vous dire qu'on ne plaisante pas.
Et pour éviter au maximum les surprises ou les changements impactant le code, on va taper dans des valeurs sûres (Microsoft, Sun, etc.)
Tout manquement aux termes du contrat coute cher à ces entreprises.
S'il faut absolument passer par un changement de contrat dans la manière d'utiliser la librairie, cela est orchestré et planifié.
On impose au concepteur de la librairie de faire des tests de non régressions poussés
On n'attend pas de le découvrir dans la release note.

On n'écrit pas une seule ligne de code sans avoir prévu tous les cas de tests et toutes les implications
D'ailleurs, on écrit les tests unitaires avant le code de production (c'est le TDD dont parle Arioch)
On décrit également le BDD avant les tests unitaire.
On utilise des automates de tests en complément des personnes qui vont tester le produit.

On n'envisage même pas de faire la moindre modification sans passer par EBIOS.

Et j'en passe...

[wiztricks]

Une librairie, c'est un contrat.
On ne change pas un contrat comme on change de chemise.

Dit comme çà, on n'aurait pas sorti Python3...
Et les clients réticents à adopter les dernières versions sont de gros frileux qui résistent au changement.

Moi ce que je sais c'est que la réalité est toute autre: les clients résistent parce que ça coûte de tester et s'il n'y a pas de nouvelles fonctionnalités à exploiter pour justifier ce coût, ils ne vont pas se précipiter car ils savent (par expérience) que çà peut être douloureux.

Et ce n'est pas la fautes des développeurs, des outils ou des langages... juste que faire évoluer des logiciels est un exercice périlleux où on a les commerciaux qui voudraient bien pouvoir vendre cette nouvelle version au plus tôt à de nouveaux (ou d'anciens) clients qui attendent alors que l'engineering freine au regard du nombre de show-stoppers qui remontent des field-tests.

Et dans cet exercice là, la réussite à limiter la casse dépend de la maturité de l'organisation qui réalise le projet et les langages utilisés (il y en a souvent plusieurs) sont une toute petite partie du problème à adresser.

- W

[popo]

Effectivement. Quand on est passé de Python v2 à Python v3 ça a été un gros travail pour tout le monde (c'est d'ailleurs la raison qui a fait que la fin officielle de Python v2 a été repoussée de 2015 à 2020). De même Qt4 à Qt5 là aussi a été drastique (toutefois là c'est Qt C++ qui a évolué et les mainteneurs de sa version Python "PyQt" ont alors dû suivre). Mais bon tu remarqueras que c'étaient des versions majeures et non mineures

Il y a des cas de changements radicaux dans la plupart des librairies.
Et donc, on s'adapte puisqu'on a pas trop le choix.
Ce qui m'a chagriné c'est qu'on me dise que je n'ai qu'a lire les release notes.
Pour le changements dont je parle dans sqlachemy, ce n'était même pas mentionné.
Donc, oui j'ai poussé mon petit coup de gueule pour crier au scandale parce que sur de l'interprété, ce simple oubli est beaucoup plus dangereux que sur du compilé où tu auras forcément un avertissement sans avoir besoin d'un outil d'analyse complémentaire (en tout cas pour ceux que je connais).

Ok. Désolé de n'avoir pas pu te convaincre
Maintenant que peut-on y faire ? Et surtout que vas-tu faire toi vis à vis de Python ?

Pour l'encapsulation qui m'est si chère, je ne vois pas ce qu'on peut y faire.
Je suis du genre tenace et même si ce ne serait pas mon premier interpréteur (je l'ai fait pour mon ancien lycée, sur le "langage" utilisé utilisé pour apprendre les première bases algorithmique), je n'irais pas jusqu'à redévelopper mon propre interpréteur python pour imposer l'encapsulation).
Mais d'autre langages interprétés gère parfaitement l'encapsulation donc je reste convaincu que c'est possible avec python (avec un @protected par exemple).
Vive la révolution !

Plus sérieusement...
L'objectif que je me suis fixé est d'arriver à réécrire des API REST aussi sécurisées que ce que j'ai pu faire en C# et selon la même architecture (en DDD mais en poussant à l'extrême la séparation des couches).
Et ne ce serait qu'en termes de sécurité, Microsoft permet d'aller très loin.
Pour le moment, j'ai pu appliquer la grosses majorité de mes dogmes à python, j'ai pu recréer une architecture assez proche de ce que j'avais, et j'ai retourné mon premier json avec cherrypy.
Je n'ai pas encore trop regardé l'aspect sécurité mais j'ai déjà vu qu'on pouvait facilement remplir l'en-tête authorization. Restera à savoir comment gérer l'authentification par token bearer.

Pour ma part oui et non. Effectivement je suis seul sur mes projets mais je t'assure qu'ils ne sont pas one shot. Je fais un suivi de version très pointilleux. Quand j'ai porté de P2 vers P3 et de Qt4 vers Qt5 j'ai commencé par créer le dossier vierge "V+1", puis y copier tous mes sources du dossier "V" et ensuite seulement commencé à travailler. Et chaque fonction, chaque objet réécrit était alors testé.

Cela ressemble assez à ce que je ferai dans le même cas.
Moi, j'étudierai chaque routine individuellement et j'écrirai des tests unitaires pour chaque cas rencontré.
C'est un travail de fourmi, cela représente parfois des centaines voires des milliers de tests unitaires pour couvrir chaque cas.
Et une fois que je suis certain d'avoir couvert le fonctionnel de chaque routine qui sera impactés par le changement dans la librairie, je modifie ces routines.
Par contre, je suis rarement tout seul sur un projet alors plutôt que dupliquer les sources, je créer une autre branche git et fait des rebases régulier pour suivre l'évolution.
De cette manière, si quelqu'un ajoute ou modifie une routine basée sur la librairie, je peux alors adapter mes tests unitaires ou en rajouter, et ça permet également d'éviter que les branches divergent trop, et donc facilite le merge en réduisant le nombre de conflits).

Et ce n'est pas parce que je suis seul sur mes projets que je n'applique pas mes propres valeurs (qui sont proches des tiennes en plus !!!). Chaque fois que je crée un objet, je commence par tout mettre en privé. Et si plus tard je me rends compte qu'un autre objet (donc externe au premier) a besoin d'accéder à un truc du premier qui a été mis en privé, je commence alors à me demander si je dois le laisser en privé et lui rajouter un getter/setter ou alors le mettre public. Je ne dis pas que mes choix sont les meilleurs mais au-moins j'y réfléchis.

Idem.
Mon langage de prédilection est le C#.
Et par défaut, dans une classe, tout est privé (sauf le constructeur par défaut) et ce comportement me va bien.

Exact, je ne peux qu'être d'accord. Mais là encore je n'ai plus d'argument. Quand on fait intervenir l'humain on ne peut plus conclure quoi que ce soit. Je me souviens du film "Sully" qui relate l'accident qui a forcé le commandant de bord d'un boing à amerrir sur l'Hudson suite à une collision avec des oiseaux. A la fin de la commission d'enquête, toutes les simulations montrent que l'avion aurait pu revenir à La Guardia ou alors de dérouter sur une piste annexe. Là le héros prend la parole et dit "arrêtons ces conneries, toutes ces simulations partent du fait que le pilote était prévenu de la la collision et à l'extinction des moteurs que ça a entrainé. Nous nous ne nous y attendions pas et avons mis du temps à réagir. Vous voulez de l'humain, rajoutez de l'humain aux simulations" (qui en plus ont été tentées 18 fois en privé avant d'être enfin réussies). Ils rajoutent donc 37 secondes de latence entre la collision et la décision de se dérouter et là les simulations échouent. Quand on rajoute de l'humain, on ne peut plus conclure. Nous ne sommes pas des robots (malheureusement ou heureusement à toi de voir). On fait avec (en Python du moins, et là c'est heureusement moins grave qu'en avion... ). Et j'espère qu'on s'en sort. Désolé pour ton souci SQLAlchemy, moi aussi j'ai vu le post dont tu parles et j'ai été emballé et commence à m'y intéresser. Ton exemple me servira. Attention quand-même, ce n'est pas parce qu'un truc est "déprécié" qu'il en devient "interdit". Déprécié c'est une juste une étape qui dit "ce sera bientôt interdit mais ça ne l'est pas encore, vous avez le temps de changer ça"...

J'ai vu et aimé ce film.
Et comme, Sully a dit (un humain mets du temps à réagir), il n'est donc pas aussi fiable qu'un ordinateur.
Pour SqlAlchemy, puisque ce "déprécié", n'est pas mentionné, on se retrouve malheureusement dans le cas ça ne fonctionne plus du jour au lendemain, et on justement on a pas le temps de voir venir et de planifier une prise en compte (ça doit donc être fait dans l'urgence, et l'humain est encore moins efficace dans l'urgence).

Ah là oui je peux répondre. Ce n'est pas parce que certains devs sont dégueux (flemmards, glandeurs, paresseux et toute une gamme de synonymes qui va avec) que leur façon de faire doit servir de référence. A mon avis ils le paieront tôt ou tard (ou, pire, d'autres paieront pour eux !!!)

Sauf que malheureusement, je dois travailler avec ce genre d'individu.
Heureusement, notre politique impose l'utilisation de Pull Request et le contrôle du code par un pair.
Je peux donc refuser le push si un dev prend trop de raccourci à mon gout.
La phrase qui me fait sortir de mes gonds : "C'est plus simple comme ça...", ou sa variante "C'est plus rapide à écrire comme ça..."
Ma réponse systématique à cette ignominie : "Le but est que ce soit simple et rapide pour le CLIENT, ton confort personnel n'entre pas en compte".
On se fait chier à établir une architecture pour faciliter la maintenance, pour qu'une modification de la base n'impacte pas le code métier mais uniquement la couche d'accès aux données, etc.
Pour moi, ii une personne n'est pas assez rigoureuse pour respecter l'architecture en place ou pense que cette architecture ne sert qu'a complexifier le projet c'est qu'elle s'est trompée de métier.

[Sve@r]

Une librairie, c'est un contrat.
On ne change pas un contrat comme on change de chemise.

Ce n'est pas ce qu'on a (ce que j'ai) pu remarquer. Les changements P2/P3 concernaient des versions majeures et l'analogie avec le changement de chemise est exagéré (c'est pas toujours sain les analogies en fait !!!). D'autant plus que cela a été suivi ensuite pendant 7 ans. Idem Qt4 vs Qt5 (et eux c'est pas Python).
Si tu veux en savoir plus sur la façon qu'on les devs Python de gérer un contrat, une explication détaillée est ici: https://sametmax2.com/la-notation-de...ver/index.html.

Je suis passé par pas mal de langage durant ma carrière : C#, Delphi, Delphi.Net, Java, VB, VB.Net, PHP, ASP (qui sont tous des langages objets et certains sont même interprétés)
N'importe quel développeur sur ces langages s'étonnerai de voir le principe d'encapsulation totalement ignoré.
N'importe quel développeur sur ces langages s'étonnerai de constater que c'est le nom de la méthode qui en fait une méthode protégée.

Dans cette liste je ne vois guère que PHP qui est interprété. Et quand tu as mentionné sa façon de protéger les attributs, wiztricks t'a donné en retour un outil qui, semble-t-il, permet de passer outre (je ne peux pas juger je ne connais pas assez PHP pour ça, juste que j'ai lu sa réponse et suis allé voir ce que en disait la doc).

Et je vais commencer par reprendre l'exemple de SqlAlchemy
Il est bourré de vulnérabilités :
https://nvd.nist.gov/vuln/detail/CVE-2019-7164
Exit direct.

Mouais. Mieux vaut le contrat annuel que passe le Ministère de la Défense avec Microsoft, eux ils sont connus pour leur fiabilité et surtout leur honnêteté. Sans déconner moi aussi je bosse dans le militaire, et j'en vois passer des notices disant "tel outil est vulnérable à truc" sauf que la notice continue par "on va mettre en place le patch qui corrige". Pourquoi "exit direct" ? Parce qu'il a des failles ? Me semble que beaucoup d'autres en ont aussi. Tiens par exemple Postgres, tu utilises? Pourtant cette BDD ne respecte pas la norme SQL demandant à ce qu'un nom de contrainte soit unique dans la bdd https://www.developpez.net/forums/d1.../#post10256588. En plus elle bourrée de vulnérabilités. Et concernant le contrat... jusqu'à la version 9 on récupérait la valeur max d'une séquence par select max_value from nom_schema.nom_sequence. Maintenant c'est select "pg_sequences"."max_value" from "pg_sequences" where "pg_sequences"."schemaname"='nom_schema' and "pg_sequences"."sequencename"='nom_table'. Mais ce n'est toujours pas mis à jour dans la doc de la v14 (page 1797, il y est toujours indiqué "Bien qu'il ne soit pas possible de mettre à jour une séquence en accédant directement à la table, une requête telle que :SELECT * FROM nom; peut être utilisée pour examiner les paramètres et l'état courant d'une séquence").

Mais peut-être Postgres ne te convient pas car tu préfères Oracle... et ses vulnérabilité. Ou sybase ? mysql ? apache ? Mais bon au-moins ssh, "le" truc qui sert à se connecter à distance ça au-moins c'est un outil sûr !!! Ah ben non en fait.. https://www.cvedetails.com/vulnerabi...d-120/SSH.html...

Voilà, des failles il y en a de partout y compris dans les outils full objet...

[popo]

Dit comme çà, on n'aurait pas sorti Python3...
Et les clients réticents à adopter les dernières versions sont de gros frileux qui résistent au changement.

Moi ce que je sais c'est que la réalité est toute autre: les clients résistent parce que ça coûte de tester et s'il n'y a pas de nouvelles fonctionnalités à exploiter pour justifier ce coût, ils ne vont pas se précipiter car ils savent (par expérience) que çà peut être douloureux.

Et ce n'est pas la fautes des développeurs, des outils ou des langages... juste que faire évoluer des logiciels est un exercice périlleux où on a les commerciaux qui voudraient bien pouvoir vendre cette nouvelle version au plus tôt à de nouveaux (ou d'anciens) clients qui attendent alors que l'engineering freine au regard du nombre de show-stoppers qui remontent des field-tests.

Et dans cet exercice là, la réussite à limiter la casse dépend de la maturité de l'organisation qui réalise le projet et les langages utilisés (il y en a souvent plusieurs) sont une toute petite partie du problème à adresser.

- W

Dit comme ça, oui.

Tes propres mots ne font que confirmer ce que j'ai dit :
On ne change pas un contrat comme on change de chemise.
- parce que ça coute cher au consommateur
- parce que ça n'instaure pas un climat de confiance s'il faut tout recasser à chaque changement de version.

Ce n'est que mon avis, tu en fais ce que tu veux.
Mais pour moi, un changement de contrat devrait être fait uniquement s'il est nécessaire pour des raisons de sécurité ou de stabilité.

Lorsqu'une faille est détectée sur une librairie, son concepteur à l'obligation légale de mettre cette information dans l'outil qui lui sert à diffuser cette librairie.
Le consommateur de l'API est sensé regarder régulièrement s'il y a des failles dans les librairies qu'il utilisent (ici notamment https://nvd.nist.gov/).
Mais dans ce cas précis, puisqu'il s'agit d'une conséquence de la correction d'une faille de sécurité, alors le contrat est changé de façon légitime

Après, je suis d'accord avec toi sur le fait que ce n'est généralement pas le développeut qui prend la décision de changer ou non.
Par contre, son rôle est d'alerter.
Si l'entreprise décide d'ignorer l'alerte ce n'est plus son problème (je conseille toutefois de garder les échanges de mail pour se défendre en cas de litige).