/* Topic des codeurs couche-tard [3] */

The Uploader · Le 08/02/2011, à 00:29

Rolinh a écrit :

C'est vrai que Python n'est pas OO...

Bah j'ai pas souvenir qu'en Python 2.6 public/private existe...

http://docs.python.org/tutorial/classes.html#tut-private a écrit :

"Private" instance variables that cannot be accessed except from inside an object don't exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.

Python est peut-être très orienté objet, mais perso je préfère Python 3 pour ça et d'autres raisons.

Quand tu perds les notions de public/private/protected (qu'en est-il de sealed/final ?), c'est une assez grosse partie de l'intérêt de l'OO qui y passe, je trouve..

edit : HDP de fou! \o/
re-edit : vrai BN;

Dernière modification par The Uploader (Le 08/02/2011, à 00:42)

Pylades · Le 08/02/2011, à 00:36

.

tshirtman · Le 08/02/2011, à 00:58

y'a un private en python 3? oO

sauce!

The Uploader · Le 08/02/2011, à 01:03

Je crois, c'est pas sûr! ^^

edit : ah ben nan.. toujours pas d'encapsulation.

edit : real vrai BN.

Dernière modification par The Uploader (Le 08/02/2011, à 01:20)

cm-t · Le 08/02/2011, à 01:40

'Nuit;

Кຼزດ · Le 08/02/2011, à 02:12

The Uploader a écrit :

Quand tu perds les notions de public/private/protected (qu'en est-il de sealed/final ?), c'est une assez grosse partie de l'intérêt de l'OO qui y passe, je trouve..

Euh non, c'est juste une manière de coder différente, beaucoup plus flexible, puisque plus sous le coup de l'encapsulation maximale. Mais l'intérêt reste le même.
(d'ailleurs, j'ai jamais compris l'intérêt de getters/setters dans le cadre de valeurs non calculées…)

nesthib · Le 08/02/2011, à 03:22

plop

samυncle · Le 08/02/2011, à 03:47

.

Compteur du TdCCT · Le 08/02/2011, à 07:42

Scores totaux, depuis le début :

1) 2516    nesthib
2) 2369    samuncle
3) 2033    Pylade
4) 1628    Кຼزດ
5) 1272+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1211    cm-t
7) 843    Р☢w ! ✰ :mad: ✰ (эй !)
8) 823    helly
9) 783    \\Ouranos//
10) 659    gnuuat
11) 538    Lagierl
12) 400    tshirtman
13) 218    Rolinh
14) 196    Askelon
15) 190    The Uploader
16) 189    Kanor
17) 172    nathéo
18) 121    ǤƦƯƝƬ
19) 93    petifrancais
20) 78    edge_one
20) 78    pierguiard
22) 74    kamui57
23) 70    gulp
24) 39    Le Rouge
25) 37    ilagas
26) 34    :!pakman
27) 30    keny
28) 25    GentooUser
28) 25    Morgiver
28) 25    xapantu
31) 24    ไ୦บเઢ'
31) 24    Steap
33) 20    CROWD
33) 20    d10g3n
35) 18    Ph3nix_
36) 15    timsy
37) 14    kouskous
38) 12    stratoboy
38) 12    sailing
38) 12    sakul
41) 11    alexises
41) 11    Crocoii
43) 10    Toineo
43) 10    NutMotion
43) 10    pseudovingtcinqcaracteres
43) 10    pfriedZ
43) 10    CasseTaTele
48) 9    gustare
49) 8    Mornagest
50) 7    Vista
51) 6    Zeibux
51) 6    ubuntlin
51) 6    asma.geek
54) 5    tendances-tdct
54) 5    kinouchou
56) 4    danychou56
56) 4    Neros
56) 4    Biaise
56) 4    totoflute
56) 4    pinballyoda ㋛
56) 4    NLS le pingouin
62) 3    Revan26914
63) 2    SoJaS
63) 2    ceric
65) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 08/02/2011, à 07:42

Scores de la période en cours :

1) 60    nesthib
1) 60    samuncle
3) 42    grim7reaper
4) 39    Pylade
5) 37    Кຼزດ
6) 30    cm-t
7) 29    Р☢w ! ✰ :mad: ✰ (эй !)
8) 26    The Uploader
9) 21    helly
9) 21    Rolinh
11) 13    :!pakman
12) 9    gnuuat
12) 9    tshirtman
14) 4    NLS le pingouin

The Uploader · Le 08/02/2011, à 08:42

Кຼزດ a écrit :

The Uploader a écrit :
Quand tu perds les notions de public/private/protected (qu'en est-il de sealed/final ?), c'est une assez grosse partie de l'intérêt de l'OO qui y passe, je trouve..
Euh non, c'est juste une manière de coder différente, beaucoup plus flexible, puisque plus sous le coup de l'encapsulation maximale. Mais l'intérêt reste le même.
(d'ailleurs, j'ai jamais compris l'intérêt de getters/setters dans le cadre de valeurs non calculées…)

Mouais... L'encapsulation reste une des notions fondamentales de l'OO... Je vois pas ce qu'il y a de plus flexible, car ce qui est précédé d'un underscore est considéré comme private et à ne pas utiliser selon la convention décrite dans la doc'.. (sinon tu fais juste du code qui va se casser la gueule le jour où ce qui est privé change..)

Et puis à la limite perdre public/private pourquoi pas (même si c'est anti OO), mais perdre aussi protected et final, ça limite trop le langage du point de vue OO..

(d'ailleurs, j'ai jamais compris l'intérêt de getters/setters dans le cadre de valeurs non calculées…)

Il est sûr que si tu met des get et des set (ces derniers ne vérifiant rien dans ton code) pour tous les champs privés de ta classe c'est pas mieux que de mettre tous tes champs en public..

Dans ces cas-là, j'en fait plutôt une inner-class privée si elle sera utilisée par une seule classe, ou je revois la nécessité de tant de get/set, ou mon découpage OO..

Dernière modification par The Uploader (Le 08/02/2011, à 09:24)

tshirtman · Le 08/02/2011, à 10:25

un setteur n'est pas forcément

set_x(self, x):
    self.x = x

ça peut être:

set_x(self,x):
    if x >= 0:
        self.x = x
    else:
        raise ValueError("attribute cannot be set to value lower than 0")

ou d'autres choses plus sofistiquées.

mais sinon, le décorateur @property c'est plus propre que les getters et les setteurs je trouve.

edit: "final" j'ai toujours trouvé ça débile, ça veux dire que personne ne pourras rien construire basé là dessus, que tu pense que t'es assez intélligent pour prévoir tout ce qui est faisable de bon ou pas avec ta classe, et prendre une telle décision…

Dernière modification par tshirtman (Le 08/02/2011, à 10:27)

The Uploader · Le 08/02/2011, à 10:45

tshirtman a écrit :

un setteur n'est pas forcément
set_x(self, x):
    self.x = x
ça peut être:
set_x(self,x):
    if x >= 0:
        self.x = x
    else:
        raise ValueError("attribute cannot be set to value lower than 0")
ou d'autres choses plus sofistiquées.

Ben justement, pourquoi alors ne pas avoir de public/private (sans ça, on peut passer outre les setters, donc exit les vérifications..).. C'est anti-OO, c'tout. C'est pas "plus flexible"! C'est plus crade.

mais sinon, le décorateur @property c'est plus propre que les getters et les setteurs je trouve.

Si ça fait comme les fameuses properties du C#, même sentence.

edit: "final" j'ai toujours trouvé ça débile, ça veux dire que personne ne pourras rien construire basé là dessus, que tu pense que t'es assez intélligent pour prévoir tout ce qui est faisable de bon ou pas avec ta classe, et prendre une telle décision…

Ouais enfin, c'est surtout protected qui m'intéresse limite plus que public/private.
Quant à final/sealed, c'est utile parfois:

http://stackoverflow.com/questions/554894/why-does-the-sealed-keyword-exist-in-net a écrit :

Designing classes and frameworks to be extensible isn't trivial, and inheritance isn't the single principle of Object Oriented programming.
So sealed preserves the developers intentions and makes their life easier. It allows the developer to control how the class is used, and allows them to make internal changes without worrying about breaking changes to code in the wild.
One principle is that you should seal any leaf class by default. Then when you create an unsealed class it forces you to think about extensibility.

Dernière modification par The Uploader (Le 08/02/2011, à 12:29)

tshirtman · Le 08/02/2011, à 15:42

http://www.h4ck3r.net/2011/02/02/what-c … n-2k-of-c/

pas mal de trucs intéressants sur ce site (malgrès le nom un peu kikoolol, il semble mériter le titre de hacker, le mec), dont un interpreteur python web client-side (au revoir javascript?), y'a même un binding webgl, mais ça semble pas marcher chez moi (ni firefox-4, ni chrome, alors que les exemples webgl que je trouve ailleurs marchent).

@the uploader: il doit bien y avoir moyen d'écrire un décorateur de classe qui rends les attributs "_*" inaccessible pour les gens du dehors, mais je ne le voit pas comme ça… le mec qui décide de taper sur un truc en _, c'est sa faute si son code crash que ce soit après une mise à jours ou pas, c'est aussi simple que ça. Python te laisse jouer si tu pense que tu sais ce que tu fais, mais t'as intérêt à avoir raison.

Et c'est la même pour les final, si tu étends une classe, c'est à toi de savoir ce que tu fait.

edit: pour être plus clair, aussi bon qu'on soit, on ne peux pas penser à tout, ce n'est pas une raison pour limiter les gens qui veulent étendre nos projets, et les forcer à parfois faire des horreurs comme forker en internet une lib juste pour enlever un final, ou réécrire des montagnes de code déjà écrites, disponible et tout, dans son coin. (par ce que oui, je l'ai vu, le contournement de final, in the wild, c'est pas joli joli).

Dernière modification par tshirtman (Le 08/02/2011, à 15:46)

The Uploader · Le 08/02/2011, à 16:06

edit: pour être plus clair, aussi bon qu'on soit, on ne peux pas penser à tout, ce n'est pas une raison pour limiter les gens qui veulent étendre nos projets, et les forcer à parfois faire des horreurs comme forker en internet une lib juste pour enlever un final, ou réécrire des montagnes de code déjà écrites, disponible et tout, dans son coin. (par ce que oui, je l'ai vu, le contournement de final, in the wild, c'est pas joli joli).

Ah ben j'dis pas que je l'utilise (final/sealed), mais les gens qui font les choses comme le .NET framework doivent avoir de sacrées bonnes raisons.
Mais impossible de retrouver les liens (ça date du temps où j'étais sous Windows tout ça Et je n'ai pas envie de regarder du côté de Java)

@the uploader: il doit bien y avoir moyen d'écrire un décorateur de classe qui rends les attributs "_*" inaccessible pour les gens du dehors, mais je ne le voit pas comme ça… le mec qui décide de taper sur un truc en _, c'est sa faute si son code crash que ce soit après une mise à jours ou pas, c'est aussi simple que ça. Python te laisse jouer si tu pense que tu sais ce que tu fais, mais t'as intérêt à avoir raison.

Ouais, mais toujours est-il qu'au moins protected pourrait être utile quand on fait ses classes et qu'on a des héritages un peu étranges. Or, protected n'existe pas en Python. Ni la moindre notion d'encapsulation d'ailleurs.
Alors faudrait arrêter de dire qu'il est full-OO / OO-to-the-core / whatever... Ce n'est pas au mauvais langage pour autant, hein.. (l'OO ne résoud pas tout, loin de là).
Mais il y a un moment où il faut savoir reconnaître les limites de son langage préféré..

Dernière modification par The Uploader (Le 08/02/2011, à 16:25)

tshirtman · Le 08/02/2011, à 16:28

wikipedia, encapsulation a écrit :

Almost always there is a way to override such protection - usually via reflection API (Ruby, Java, C# etc.), sometimes by mechanism like name mangling (Python), or special keyword like friend in C++. This access is often necessary for debuggers, serialization, unit testing, but not uncommonly in normal code when private was overeagerly applied.

(page intéressante, aussi par le fait que l'encapsulation ne contient pas forcément la protection)

protected se réalise de la même manière que private, avec une vérification de isinstance(object, class) pour savoir si c'est une classe fille, c'est pas difficile…

Dernière modification par tshirtman (Le 08/02/2011, à 16:32)

grim7reaper · Le 08/02/2011, à 17:12

The Uploader a écrit :

Mais il y a un moment où il faut savoir reconnaître les limites de son langage préféré..

Mission quasi-impossible pour la majorité des python-user que j'ai croisé (heureusement, il y a quelques exceptions).
Leur langage c'est LE langage…

Dernière modification par grim7reaper (Le 08/02/2011, à 17:13)

tshirtman · Le 08/02/2011, à 17:47

Ce ne sont pas des limites, puisque c'est parfaitement faisable dans le langage, ce n'est juste pas la philosophie du langage…

(les décorateurs, et au pire, les métaclasses, permettent ce genre de choses)

The Uploader · Le 08/02/2011, à 17:53

Faire des choses 'simples' par des moyens détournés n'est jamais une bonne idée..

helly · Le 08/02/2011, à 17:55

Bon, je me remet un bon coup dans la traduction !
Jpense finir la page starting-out ce soir. Puis correction des 'tites fautes demain.

Kanor · Le 08/02/2011, à 19:49

>>> class A(object):
...     def __test(self):
...         print "TEST"
... 
>>> a = A()
>>> a.__test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'A' object has no attribute '__test'

Dans cette exemple la méthode est bien privé ou j'ai raté un épisode.

Dernière modification par Kanor (Le 08/02/2011, à 19:49)

grim7reaper · Le 08/02/2011, à 20:26

Java :]

tshirtman · Le 08/02/2011, à 20:46

gaby@fofinho:~$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
...     def __init__(self):
...             self.__a = True
... 
>>> 
>>> A()
<__main__.A object at 0xb77f5b8c>
>>> A().__a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'A' object has no attribute '__a'
>>> 
>>> A().__dict__['__a']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: '__a'

en effet, ça semble être du vrai private (pas protected), et je ne vois pas de contournement à priori…
(j'ai vérifié avec une classe fille)

grim7reaper · Le 08/02/2011, à 20:47

A().__dict__['__a']

Ptain, faut avouer que c'est parfois super élégant le Python (c'est du même niveau esthétique que les templace en C++)

Dernière modification par grim7reaper (Le 08/02/2011, à 20:50)

tshirtman · Le 08/02/2011, à 20:48

c'est de l'introspection… montre moi comment on fait ça en java pour voir (ou en C++, qu'on rigole ^^)

Dernière modification par tshirtman (Le 08/02/2011, à 20:48)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1826 Le 08/02/2011, à 00:29

Re : /* Topic des codeurs couche-tard [3] */

#1827 Le 08/02/2011, à 00:36

Re : /* Topic des codeurs couche-tard [3] */

#1828 Le 08/02/2011, à 00:58

Re : /* Topic des codeurs couche-tard [3] */

#1829 Le 08/02/2011, à 01:03

Re : /* Topic des codeurs couche-tard [3] */

#1830 Le 08/02/2011, à 01:40

Re : /* Topic des codeurs couche-tard [3] */

#1831 Le 08/02/2011, à 02:12

Re : /* Topic des codeurs couche-tard [3] */

#1832 Le 08/02/2011, à 03:22

Re : /* Topic des codeurs couche-tard [3] */

#1833 Le 08/02/2011, à 03:47

Re : /* Topic des codeurs couche-tard [3] */

#1834 Le 08/02/2011, à 07:42

Re : /* Topic des codeurs couche-tard [3] */

#1835 Le 08/02/2011, à 07:42

Re : /* Topic des codeurs couche-tard [3] */

#1836 Le 08/02/2011, à 08:42

Re : /* Topic des codeurs couche-tard [3] */

#1837 Le 08/02/2011, à 10:25

Re : /* Topic des codeurs couche-tard [3] */

#1838 Le 08/02/2011, à 10:45

Re : /* Topic des codeurs couche-tard [3] */

#1839 Le 08/02/2011, à 15:42

Re : /* Topic des codeurs couche-tard [3] */

#1840 Le 08/02/2011, à 16:06

Re : /* Topic des codeurs couche-tard [3] */

#1841 Le 08/02/2011, à 16:28

Re : /* Topic des codeurs couche-tard [3] */

#1842 Le 08/02/2011, à 17:12

Re : /* Topic des codeurs couche-tard [3] */

#1843 Le 08/02/2011, à 17:47

Re : /* Topic des codeurs couche-tard [3] */

#1844 Le 08/02/2011, à 17:53

Re : /* Topic des codeurs couche-tard [3] */

#1845 Le 08/02/2011, à 17:55

Re : /* Topic des codeurs couche-tard [3] */

#1846 Le 08/02/2011, à 19:49

Re : /* Topic des codeurs couche-tard [3] */

#1847 Le 08/02/2011, à 20:26

Re : /* Topic des codeurs couche-tard [3] */

#1848 Le 08/02/2011, à 20:46

Re : /* Topic des codeurs couche-tard [3] */

#1849 Le 08/02/2011, à 20:47

Re : /* Topic des codeurs couche-tard [3] */

#1850 Le 08/02/2011, à 20:48

Re : /* Topic des codeurs couche-tard [3] */

Pied de page des forums