PRENEUR DE CHOIX, PRISE DE DECISION, COMPARAISON D ELEMENT
saigneurdushi
Messages postés
45
Date d'inscription
samedi 3 mai 2003
Statut
Membre
Dernière intervention
25 janvier 2011
-
23 oct. 2010 à 23:19
aera group Messages postés 382 Date d'inscription mercredi 23 août 2006 Statut Membre Dernière intervention 8 novembre 2010 - 6 nov. 2010 à 18:01
aera group Messages postés 382 Date d'inscription mercredi 23 août 2006 Statut Membre Dernière intervention 8 novembre 2010 - 6 nov. 2010 à 18:01
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/52410-preneur-de-choix-prise-de-decision-comparaison-d-element
https://codes-sources.commentcamarche.net/source/52410-preneur-de-choix-prise-de-decision-comparaison-d-element
6 nov. 2010 à 18:01
De manière général au niveau de la sécurité, soit tu "blinde" tes fonctions avec des try/except et des if/else ou bien tu t'arrange pour ne pas faire d'erreur quand tu les utilises.
Au passage le "blindage" des fonctions devient obligatoires quand on attend des données de l'utilisateur.
6 nov. 2010 à 02:24
C'est un de mes premier code orienté objet donc je comprend ta reaction,
Mais j'avoue ?tre depassé légerement par ce paradoxe...
si "Le choix en Python est la liberté totale ..." pourquoi n ai je pas la liberté d imbriquer mes classes tranquillement ? =)
Humour je précise car j avais bien remarquer lors de la conception du code que ca limite l'accès au fonction et au classe lui appartenant, et je t avouerais même l'avoir fait volontairement dans un pseudo souci de securité. Car je trouvais étonnant qu'un objet ai les plein accès (meme si il ne les utilise pas) au fonction garantissant son existence ?
Et puis l optique à terme c'est que chaque monde est la possibilité de se charger avec un environnement different pour faire des statistique sur la maniere dont la liste des meilleur element peuvent varier.
La question logique est donc comment puis je m'assurer qu'un objet n est pas accès à un autre alors qu il existe dans une même structure ?
En tout cas merci d avance.
Cdlt
5 nov. 2010 à 20:49
Des classes dans des classes c'est interdit !!!!
>> Oui mais pourtant l'interpréteur Python ne génère pas d'erreur.
En effet, Python accepte des imbrications de classes et les imbrications de fonctions (fonction dans une fonction), mais par convention, on ne crée des fonctions que dans des classes ou que dans le corps du programme. De même on ne crée les classes que dans le corps du programme.
>> Mais pourquoi ?
Parce que premièrement, la plus part des langages Objets interdisent les imbrications de classe ou de fonction. Dans un soucis de conformisme et pour permettre le travail des compilateurs inter langage on respect cette règle.
La deuxième raison est qu'une classe ou une fonction imbriqué n'est disponible que dans la classe ou la fonction qui la contient. En claire vous ne pouvez pas l'instancer/appeler si vous n'êtes pas dans la classe/fonction qui contient elle même la classe/fonction.
Et ça c'est mal !! Pourquoi ? Parce que en Python comme en C++ est autre, tout les objets, variables, fonctions, ... sont capable dans tout le programme à la différence de certain langage comme Java qui possède pour chaque attribut, classes, fonction, ... un paramètre private ou public (et même protected).
Le choix en Python est la liberté totale, respecte ce choix.
Tu n'es pas le premier à le faire, mais corrige ça c'est plutôt mal vu, et surtout ca gâche tout le code qui du coup parait mal fait.
Enfin dernière petite remarque avant ma lecture, inutile de faire hérité tes classes de objects, en Python c'est fait automatiquement ...
3 nov. 2010 à 15:21
1 nov. 2010 à 00:58
31 oct. 2010 à 22:45
De plus il existe une fonction sort qui permet de trier une liste. [-1:] permet de sortir le dernier élément de la liste donc, le plus fort.
Pour mieux comprendre :
liste = [2,3,1,7,0]
liste.sort()
print (liste[-1:])
Voila, devient acteur de cette source en l'améliorant au lieux d'être juste recopieur (moine copiste est un métier qui se perd ... :p)
23 oct. 2010 à 23:19