Discussion :

[wiztricks]

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é.

A partir du moment où on est contraint d'évoluer et que ça met en œuvre une organisation humaine, la bonne volonté ne suffit pas à garantir la qualité: il va falloir "tester".

Ce qui peut paraître gênant avec les langages interprétés est que le renommage sauvage d'une variable ou d'un attribut ne sera détecter que lorsque l'interpréteur exécutera l'instruction qui...
Avec un langage compilé, l'erreur sera détectée par le compilateur: bien plus tôt.

Avec un langage interprété, il va falloir faire une analyse statique du code avec des outils comme pylint (déjà mentionné par Pyramidev), mypy,... ou avoir une excellente couverture du code par le jeu de tests.
Et on a une solution raisonnable pour détecter les problèmes du à ces changements (avant de faire "run").

A partir du moment où le problème est gérable de façon raisonnable, je suis content.

- W

[popo]

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.

. Si les concepteurs font une version et qu'il faut 7 ans pour stabiliser le bouzin, ça donne pas vraiment envie de s'y intéresser.

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).

ASP aussi est interprété. Ne pas confondre avec ASP.Net.
Concernant PHP et sa manière de passer outre la protection, j'ai déjà répondu qu'un débutant ne saura pas contourner facilement, contrairement à python qui ne s'en préoccupe même pas.

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...

Concernant les vulnérabilités, je suis entièrement d'accord avec toi sauf sur un léger détail que tu sembles avoir zappée et qui pourtant aurait dû te sauter aux yeux pour quelqu'un travaillant dans le militaire.

PostgreSql (que je n'utilise pas entre autre pour son interprétation douteuse de la norme SQL) souffre de failles. Certes, comme tous les autres SGBD, et comme n'importe quelle librairie de n'importe quel langage. Mais la grosse différence (celle qui aurait dû te sauter aux yeux et qui explique mon "exit direct") est que les types qui developpent PostgreSql poussent régulièrement des modifications pour palier à ces failles. Les types qui ont développé Sqlalchemy n'ont rien fait pour remédier à la situation depuis 2019 (sur une faille évaluée critique), et n'ont poussé une modif que très récemment. Les militaires sont devenus bien laxistes depuis que j'ai quitté le secteurs parce qu'à l'époque jamais on ne se serait appuyé sur une librairie dont les failles sont ignorées pendant deux ans ou qui semble laissée à l'abandon.

[Sve@r]

. Si les concepteurs font une version et qu'il faut 7 ans pour stabiliser le bouzin, ça donne pas vraiment envie de s'y intéresser.

Euh non tu n'as pas bien compris.
P3 est sorti en 2007. Mais son incompatibilité complète avec P2 (un script P3 pourra probablement tourner sous P2 dans 90% des cas, un script P2 tournera sous P3 dans 0.5% des cas) a alors amené la communauté a assurer une évolution en parallèle des deux versions. Pour laisser le temps aux librairies d'être porté sous P3 (*). Ce parallèle devait se terminer en 2015.
Ce travail massif ayant pris plus de temps que prévu, la date a été reculée au 1/1/2020.. Mais en 2007 à sa sortie il était quand-même assez stabilisé pour commencer à être utilisé. En fait je ne sais pas pourquoi j'ai dit 7 ans... car ça a été en fait 12 ans (parce que entre 1/1/2020 et 31/12/2019...). Mais 12 ans d'évolution, pas de stabilisation.

(*) tu aurais vu les forums Python à l'époque... il était enflammé. Personne ne voulait de P3 et des conséquences. Il y avait des benchmarks de partout montrant que P2 était plus rapide que P3. Je pense que le plus gros souci a été à cause des strings P3 devenues unicode face aux strings P2 encodées en ascii. Moi j'ai commencé à y penser en 2018 et je m'y suis mis en 2019. Ceci dit je ne regrette pas car si on y rajoute les simplifications apportées par Qt5 face à Qt4, mes codes ont diminué d'à peu près 10%.

ASP aussi est interprété. Ne pas confondre avec ASP.Net.

Ah ok, en effet j'ai confondu...

Concernant PHP et sa manière de passer outre la protection, j'ai déjà répondu qu'un débutant ne saura pas contourner facilement,

Et un truc qui s'appuie sur l'ignorance vaut-il mieux qu'un truc qui s'appuie sur le bon vouloir? Accessoirement j'ai lu dans un livre de Marco Wolf la phrase suivante "l'ignorance est de courte durée, la connaissance reste à vie". Le débutant ne saura pas le contourner facilement mais il ne restera pas débutant.

Concernant les vulnérabilités, je suis entièrement d'accord avec toi sauf sur un léger détail que tu sembles avoir zappée et qui pourtant aurait dû te sauter aux yeux pour quelqu'un travaillant dans le militaire.
PostgreSql (que je n'utilise pas entre autre pour son interprétation douteuse de la norme SQL) souffre de failles. Certes, comme tous les autres SGBD, et comme n'importe quelle librairie de n'importe quel langage. Mais la grosse différence (celle qui aurait dû te sauter aux yeux et qui explique mon "exit direct") est que les types qui developpent PostgreSql poussent régulièrement des modifications pour palier à ces failles. Les types qui ont développé Sqlalchemy n'ont rien fait pour remédier à la situation depuis 2019 (sur une faille évaluée critique), et n'ont poussé une modif que très récemment.

Ok, je vois ce que tu veux dire. Après on parle d'une librairie (qu'en plus je ne connais pas et n'utilise pas encore, si tu te souviens j'ai dit "j'ai vu le post qui en parle et ça m'intéresse"). Mais je regarderai si je peux y faire du sql-inject comme c'est décrit dans cette page. Et bon si tu es allé voir le lien quand j'ai parlé de Postgres effectivement ils interprètent la norme à leur façon (le souci de nom de contrainte non unique dont je parle dans cet autre topic existe toujours avec la v11 et existera probablement ad vitam) mais je fais avec. Pour la petite histoire, quand j'ai eu à choisir entre Postgres ou MySQL, j'avais déjà touché aux deux mais mon expérience MySQL était plus récente donc j'ai commencé avec cette bdd.
Puis quelque temps après, je me suis rendu compte que MySQL (à l'époque car ça a dû changer depuis) ne savait pas gérer les contraintes de clef étrangère sur une clef composée de plusieurs champs. Alors que Postgres savait. Plus sa syntaxe bizarre à base de backquotes pour encadrer ses strings alors j'ai basculé. Je veux dire par là que de partout on trouvera des avantages et inconvénients et qu'il faut savoir composer avec ; et même parfois choisir, et même parfois abandonner si l'inconvénient est trop critique. J'espère ne pas avoir à abandonner Python. Toutefois j'ai eu un petit truc à faire récemment, le client voulait du compilé car il travaille sur des embarqués et Python était trop gros pour son truc donc je l'ai fait en C++. Bon c'était juste un traitement de fichier, pas d'IHM rien. Et même pour ce truc standalone (juste 800 lignes) j'ai quand-même travaillé en private/public.

[cegehi]

Vous êtes partis un peu loin par rapport à ma question de départ, non?

[popo]

Vous êtes partis un peu loin par rapport à ma question de départ, non?

Tu trouves ?

Euh non tu n'as pas bien compris.
P3 est sorti en 2007. Mais son incompatibilité complète avec P2 (un script P3 pourra probablement tourner sous P2 dans 90% des cas, un script P2 tournera sous P3 dans 0.5% des cas) a alors amené la communauté a assurer une évolution en parallèle des deux versions. Pour laisser le temps aux librairies d'être porté sous P3 (*). Ce parallèle devait se terminer en 2015.
Ce travail massif ayant pris plus de temps que prévu, la date a été reculée au 1/1/2020.. Mais en 2007 à sa sortie il était quand-même assez stabilisé pour commencer à être utilisé. En fait je ne sais pas pourquoi j'ai dit 7 ans... car ça a été en fait 12 ans (parce que entre 1/1/2020 et 31/12/2019...). Mais 12 ans d'évolution, pas de stabilisation.

(*) tu aurais vu les forums Python à l'époque... il était enflammé. Personne ne voulait de P3 et des conséquences. Il y avait des benchmarks de partout montrant que P2 était plus rapide que P3. Je pense que le plus gros souci a été à cause des strings P3 devenues unicode face aux strings P2 encodées en ascii. Moi j'ai commencé à y penser en 2018 et je m'y suis mis en 2019. Ceci dit je ne regrette pas car si on y rajoute les simplifications apportées par Qt5 face à Qt4, mes codes ont diminué d'à peu près 10%.

Je ne peux que comprendre cette réaction.
Le passage des String en Unicode a été une sacré révolution également en Delphi.
Elle a duré moins longtemps car le compilateur s'est mis à remonter des warnings et nous indiquait chaque ligne concernée.
Mais, je trouve fou qu'une librairie oblige à réécrire 99.5% du code !!

Et un truc qui s'appuie sur l'ignorance vaut-il mieux qu'un truc qui s'appuie sur le bon vouloir? Accessoirement j'ai lu dans un livre de Marco Wolf la phrase suivante "l'ignorance est de courte durée, la connaissance reste à vie". Le débutant ne saura pas le contourner facilement mais il ne restera pas débutant.

S'il s'appuies uniquement sur l'ignorance, non.
Mais s'il s'appuie sur l'ignorance (pour les débutants) ET sur le bon vouloir (pour les autres), oui je trouve que c'est mieux.
Pour un débutant, si le système ne le laissera pas faire, il ne prendra pas l'habitude de le faire. Lorsqu'il aura plus de bouteille, ce comportement sera ancré et même s'il découvre le moyen de contourner, il ne le fera pas à moins d'avoir une excellente raison.
Je trouve ça effectivement plus sain qu'un système qui te laisse faire, justement parce qu'un débutant n'aura pas forcément conscience de la convention et qu'il risque de prendre de mauvaises habitudes.

[Sve@r]

Vous êtes partis un peu loin par rapport à ma question de départ, non?

Ca peut arriver mais c'est bien. Ca veut dire que ta question a créé le débat. Tu aurais demandé "pensez-vous qu'il fera beau demain?" ton topic aurait fait le flop

Mais, je trouve fou qu'une librairie oblige à réécrire 99.5% du code !!

Là pareil, petite incompréhension. Les 99.5% ce n'est pas une librairie (je pense que tu parles de Qt4/Qt5), c'est le changement P2 à P3. Le souci c'est pas "juste" les strings en unicode, c'est "zut, la librairie X utilise les strings ascii, il faut maintenant que je convertisse tout ce qui vient de cette librairie et tout ce que j'y envoie". Et pareil dans l'autre sens "zut, la librairie Y était en unicode donc je faisais des conversions qu'il me faut maintenant supprimer". Parce que Python ce n'est pas QUE Python. Certaines librairies sont écrites dans d'autres langages pour être plus rapides. Et de fait ce n'est pas parce que Python change que la librairie change en parallèle.
Et ensuite on rajoute les différences tels les trucs disparus (xrange(), unicode(), cmp(), dict.itertrucs(), dict.viewtrucs()) ou changés (le raw_input() P2 renommé en input() P3 remplaçant par là le input() P2 qui travaillait différemment => il faut donc revoir tous les input() pour les adapter à la version P3 avant de remplacer raw_input() par input()), la syntaxe qui se renforce (print devenu fonction, except Exception, e devenu except Exception as e), de nouveaux outils arrivés (exemple list.clear()) qui vide la liste permettant alors de revoir tous les codes où la liste est vidée manuellement)...

[popo]

Ca peut arriver mais c'est bien. Ca veut dire que ta question a créé le débat. Tu aurais demandé "pensez-vous qu'il fera beau demain?" ton topic aurait fait le flop


Là pareil, petite incompréhension. Les 99.5% ce n'est pas une librairie (je pense que tu parles de Qt4/Qt5), c'est le changement P2 à P3. Le souci c'est pas "juste" les strings en unicode, c'est "zut, la librairie X utilise les strings ascii, il faut maintenant que je convertisse tout ce qui vient de cette librairie et tout ce que j'y envoie". Et pareil dans l'autre sens "zut, la librairie Y était en unicode donc je faisais des conversions qu'il me faut maintenant supprimer". Parce que Python ce n'est pas QUE Python. Certaines librairies sont écrites dans d'autres langages pour être plus rapides. Et de fait ce n'est pas parce que Python change que la librairie change en parallèle.
Et ensuite on rajoute les différences tels les trucs disparus (xrange(), unicode(), cmp(), dict.itertrucs(), dict.viewtrucs()) ou changés (le raw_input() P2 renommé en input() P3 remplaçant par là le input() P2 qui travaillait différemment => il faut donc revoir tous les input() pour les adapter à la version P3 avant de remplacer raw_input() par input()), la syntaxe qui se renforce (print devenu fonction, except Exception, e devenu except Exception as e), de nouveaux outils arrivés (exemple list.clear()) qui vide la liste permettant alors de revoir tous les codes où la liste est vidée manuellement)...

Effectivement, j'avais pas compris ça comme ça.
Comme je le disais précédemment, le passage à Unicode à donné des sueurs froides à pas mal de monde, et pas qu'en python.

[wiztricks]

Et de fait ce n'est pas parce que Python change que la librairie change en parallèle.

Une bonne pratique est d'avoir un(des) adaptateur(s) (un module python) entre son code est la bibliothèque pour "lisser" les changements.

Pour ce qui est de la migration P2/P3, au début c'était duraille... mais on a vite venu arriver des outils de conversion automatique (mentionnés dans ce how-to) qui permettent même d'avoir des moutures P2 et P3 sans trop galérer.

Vous êtes partis un peu loin par rapport à ma question de départ, non?

De fait. Mais c'est un forum de discussion...

- W

[Sve@r]

Une bonne pratique est d'avoir un(des) adaptateur(s) (un module python) entre son code est la bibliothèque pour "lisser" les changements.

Hé ça c'est facile à dire après coup. Mais quand on est en 2007 on ne sait pas ce que va être le futur. Prenons par exemple le curseur psycopg2. Sa méthode execute() attend une string (la requête). Ton réflexe (je dis "ton" dans le sens "le réflexe de M. tout_le_monde) c'est directement curs.execute("... (la requête)...") parce que tu ne t'attends pas à ce qu'un élément aussi "bas niveau" que l'est la string puisse changer de nature un jour. Sinon où s'arrêter? Tu vas créer un adaptateur pour passer les strings à psycopg2 (style str2psyco())... mais si une autre méthode veut un int il lui faudra aussi un adaptateur int2psyco() parce qu'il n'y a pas de raison de faire confiance à l'imuabilité des ints si tu n'as pas fait confiance à celle des str...

[wiztricks]

tu ne t'attends pas à ce qu'un élément aussi "bas niveau" que l'est la string puisse changer de nature un jour. Sinon où s'arrêter?.

Désolé mais avec P2, il a toujours été recommandé de travailler en Unicode là ou çà fait du sens.

Tu vas créer un adaptateur pour passer les strings à psycopg2 (style str2psyco())... mais si une autre méthode veut un int il lui faudra aussi un adaptateur int2psyco() parce qu'il n'y a pas de raison de faire confiance à l'imuabilité des ints si tu n'as pas fait confiance à celle des str...

Ici, une grosse partie de mon adaptateur est réalisé par SqlAlchemy.

D'expérience d'autres vies, les utilisateurs qui ont eu de gros problèmes avec les migrations (en dehors de ce qui a pu être "relnoted") sont ceux qui ne se sont pas posés de questions au delà de "çà marche, je livre et après moi le déluge" (ce qu'on appelle aujourd'hui la "dette technique").

- W

[popo]

Désolé mais avec P2, il a toujours été recommandé de travailler en Unicode là ou çà fait du sens.

Ma question va peut-être paraitre bête mais comment tu détermines là où ça fait sens ?
Quand je regarde la documentation de psycopg2, je retrouve l'exemple qu'à donné Sve@r


Est-ce qu'en fait, ce que tu dis c'est que le code présenté dans la doc ne fonctionne pas en python 2 ?
Mais du coup, en P2, s'il fallait transformer en Unicode, la documentation de psycopg2, le précisait-elle ?
Parce que si ce n'était pas le cas, la remarque de Sve@r est compréhensible.

Ici, une grosse partie de mon adaptateur est réalisé par SqlAlchemy.

Mais si SqlAlchemy est beaucoup trop laxiste avec ces failles à mon gout, j'aime bien le principe, en tout cas la version où tu as un mappeur entre l'objet métier et l'entité de la base de données.
Je préfère mettre une couche de plus entre mon accès au données et mon métier pour éviter de changer le contrat du métier.
Tellement que j'ai moi même programmé une mécanique similaire en me basant sur le TQuery de Delphi.
Si j'avais eu besoin de le faire en python, je me serait certainement appuyé sur cursor.execute et je me serait fait avoir moi aussi.

[wiztricks]

Salut,

Ma question va peut-être paraitre bête mais comment tu détermines là où ça fait sens ?

Avec la connaissance qu'on acquiert avec l'expérience,... A défaut (par exemple lorsqu'on débute), on est obligé d'apprendre avec les savoirs disponibles. Avec Python2, on a un how-to qui est un bon début pour comprendre (un peu) les problèmes.

Est-ce qu'en fait, ce que tu dis c'est que le code présenté dans la doc ne fonctionne pas en python 2 ? Mais du coup, en P2, s'il fallait transformer en Unicode, la documentation de psycopg2, le précisait-elle ?

Avec Python2, les strings avaient le type "unicode" et les bytes était de type "str". Le gros soucis était qu'on pouvait se mélanger les pinceaux parce que l'implémentation était un peu "weak"....

Pas sûr qu'il ne laisse pas écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
name = u'toto'
cursor.execute('SELECT * FROM table WHERE name=?', (name,))

au résultat incertain plutôt que de forcer à écrire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cursor.execute(u'SELECT * FROM table WHERE name=?', (name,))

Pour le reste, c'est comme toutes les ES, si on ne précise pas l'encoding de la base à l'ouverture de la connexion, on va avoir les mêmes soucis qu'avec la lecture d'un simple fichier texte.

- W

[popo]

Le how-to n'est qu'un outil générique.
Il ne précise ce qu'il faut passer comme chaine pour une librairie donnée.

Il est possible que je n'ai pas compris la remarque de Sve@r (ou mal)

Ce que j'en avais compris c'est que psychopg2 dans sa méthode cursor.execute attendais une simple chaîne.
J'avais également compris que rien dans la documentation ne précisait à l'époque qu'il faut la passer en unicode et que du coup les gens passaient une chaine standard.
J'avais compris que puisque les gens passaient une chaine standard, le passage de P2 à P3 sur cette méthode posait problème.

Mais moi qui suis en P3, je l'ai codé comme en P2 quand j'ai fait les tuto (puisque ces tuto passent des chaines standard).
Et du coup j'ai du mal à voir où est l'incompatibilité dans cette méthode cursor.execute.
Ou alors, c'est lié à l'encoding du source python lui-même (par défaut, je l'ai configuré en utf-8) ?

[wiztricks]

Et du coup j'ai du mal à voir où est l'incompatibilité dans cette méthode cursor.execute.
Ou alors, c'est lié à l'encoding du source python lui-même (par défaut, je l'ai configuré en utf-8) ?

Avec Python2, les chaînes de caractères littérales étaient "str"/"bytes" (sauf à les préfixer par un u).

Le how-to n'est qu'un outil générique.
Il ne précise ce qu'il faut passer comme chaine pour une librairie donnée.

C'est à la documentation de chaque bibliothèque de préciser ce que les méthodes acceptent comme objets en paramètres et ce qu'elles produisent en sortie (le how-to montre par exemple os.listdir).

- W