Informatique - Mines PSI/PC/MP 2015

[Der RHDJ]

10 contre 1 que tes sources ont tort, si elles existent.

[farrell1995]

Moi sa m'arrange pas qu'on la repasse.

Je ne suis pas contre la tendance à mettre de la programmation un peu partout. Je suis juste contre qu'on en face un effet de mode plutôt qu'une reflexion sur l'intérêt de la matière en elle même. Qu'on la mette au programme alors qu'on a pas de prof compétents. Qu'on la mette aux concours alors qu'ils n'ont même pas envie de passer 2mn à voir qu'ils avaient mal encodés leurs commentaires et que c'était illisible.
J'espère juste que sa s'améliorera parce que là c'est une blague cet IPT pour tout ce que j'en ai vue, et pourtant je suis le premier à défendre des cours d'informatique / programmation en prepa et l'utilisation de Python.

[Yaeghs]

Quand tu travailles avec des classes, ce n'est pas scandaleux, mais comment ils l'ont fait ... ça c'était ridicule.

Pardon? En python, on ne fait pas de setter/getter. C'est bien connu. Get/set c'est du JAVA ou du C++ (même si, en C++, l’intérêt est déjà très limité dans bien des cas).
Python n'a pas (et c'est *voulu*) la notion de "privé".
Le scandale étant d’appeler ces fonctions get1, get2, get3...c'est horrible. C'est tout ce qu'il ne faut PAS faire.
D'ailleurs tout le code du Huffman proposé est ridicule. Le sujet prétend se baser sur un "problème industriel de la vraie vie"...ce code de merde c'est tout sauf ça.

Personnellement, (j'ai sans doute trop travaillé en c++), je ne peux pas m'empêcher d'utiliser des getteurs/setteurs à tout de bout de champ, au moins pour avoir des gardes fous vis à vis de mes variables. Après, le nom est juste ridicule, je suis tout à fait d'accord, surtout que ce ne sont pas des accesseurs à proprement parler en plus (je viens de rejeter un coup d'oeil) x)
Bah, ils se sont plantés !


Refaire passer l'épreuve ? J'aimerai bien voir ça personnellement. Ca signifie renvoyer des convocs, reréserver des salles, c'est beaucoup trop de logistique pour une simple épreuve coef 1.

[fakbill]

Yaeghs : oui oublions leur code qui ne vaut pas un clou. Plus sérieusement, en python est conçu avec "EAFP" : It is Easier to Ask for Forgiveness than Permission en tête.
http://en.wikipedia.org/wiki/Python_syn ... Exceptions
En résumé, en python, on ne teste pas avant pour être certain que ça va marcher...non...on tente le coup dans un "try" et, si le code n'est pas idiot, 99.99% du temps, ça passe. Avec un système d'exceptions bien fichu (je ne connais pas un seul langage qui propose les exceptions et qui les implémente mal...) ça coute même moins cher que de faire le test explicitement.

Pour ce qui est de la prog objet, je n'ai jamais été convaincu par "private" et encore moins par la complexité du C++ et de son "protected". Je peux comprendre qu'un langage aussi dynamique que python (ou peut TOUT changer tout le temps) pose qlqs problèmes dans des GROS projets mais je ne pense pas que la rigidité du C++ soit une solution...ça génère juste tout une économie

Ecrire get1 pour chopper le premier élément d'une liste et get2 le second est une horreur en python.
La définition d'un tuple donné dans le sujet est aussi...des plus étranges pour être poli.
En python, tout ce qui compte, c'est "mutable ou pas". Cette distinction remplace le "par valeur, pointeur ou référence" du C++...et le duck typing remplace la complexité de POO...si l'objet sait faire ce dont on a besoin alors pourquoi le refuser sous prétexte qu'il n'est pas du type prévu dans la déclaration de la fonction???

[Yaeghs]

Je ne savais pas que python était conçu justement pour éviter l'encapsulation. J'aurai appris un truc ! (C'est une question d'habitude après)
Le truc c'est que les exceptions faut les faire à chaque fois que tu as besoin de l'objet non ? A moins de les faire dans un accesseur ou de tester quand tu récupères ton objet ou ses variables (j'ai horreur de plus trouver un mot, il y a les méthodes et les ... ?)



Oui, pour accéder aux éléments de la liste c'est juste.idiot. mais je croyais que tu parlais des get en general du coup. (J'ai du mal à me faire au fait que le code proposé est idiot. Donc quand tu dis get je pense tout de suite aux accesseurs. Mea culpa =/)

[fakbill]

heu...pas exactement...reprenons
Python n'est pas conçu pour éviter quoique ce soit (sauf si c'est "proposer plusieurs façons de faire la même chose).
Python n'a pas de notion de privé ou de protected.

Le truc c'est que les exceptions faut les faire à chaque fois que tu as besoin de l'objet non

ask for forgiveness and not for permission donc oui. De toutes façons tu ne vas mettre la gestion de l'exception dans la classe...Car si l'exception se déclenche tu renvoies quoi???

On ne fait PAS de set/get pour accéder à des données membre d'une classe en python car ce n'est pas du tout dans l'esprit du langage.
Python laisse faire le programmeur. Si on veut faire n'importe quoi en python on peut.
a = 1
b = 2
a = "foo"
c'est valide mais c'est n'importe quoi.

Le duck typing apporte aussi une immense souplesse. Si un objet sais faire ce qu'on attend de lui, pourquoi le rejeter? Le système de type/héritage/template du C++ résout plus ou moins le problème mais d'une façon ultra complexe. Python voit ça d'une façon très pragmatique : si ça sait faire coin coin alors c'est un bon canard.

[ingens]

Corrigé sur http://concours-maths-cpge.fr/

[fakbill]

Ca va le correcteur se plaint...il aurait pu écrire une intro en disant que ce sujet était de la merde en barre. Ce faisant, il aurait eu toute ma sympathie

[Lothbrok]

Notre prof d'info nous a aussi signalé qu'une lettre de l'UPS allait être envoyée.
Mais bon, ça va rien changer de toute façon. Ils vont pas se bouger pour une épreuve coeff' 1 !

[fakbill]

C'est bien dommage car, bien faite, ce serait une très bonne épreuve pour sélectionner de futurs cadres scientifiques.
Tout cadre scientifique aura un jour ou l'autre à traiter de façon non ridicule (si possible ) des données.