Qui êtes-vous ? Que faites-vous ?

bruno.desthuilliers@gmail.com wrote:

On 28 fév, 10:44, Alex Marandon <a...@invalid.org> wrote:

bruno.desthuilli...@gmail.com wrote:

Pardon ? je ne comprends pas ce que tu veux dire, là ???

Heu... je ne vois pas trop ce que tu comprends pas.

Le rapport entre généricité et $@#%%%

$, @ et % seulement.
# marque un commentaire, comme en Python
Le rapport, je sais pas, je pense pas avoir dit qu'il y en avait un.

Au final, je pense que je vais garder ma solution a base de
__getattr__, nettement plus lisible, a mon tres subjectif avis.

Dommage pour toi - et pour ceux qui devront maintenir ton code.

Pourquoi ? Quels sont les avantages de la solution utilisant le protocole
descripteur ?

(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)

Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc toutes les
'règles' d'une propriété en un même endroit). Un second avantage est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).

Ok, mais si tu ajoutes plusieurs propriétés, tu dois copier toute la
plomberie ? Non, j'ímagine tu peux factoriser ça...

Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring).

Ah effectivement ça, ça me parle, tu m'as convaincu.

Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties.

C'est quoi, les règles de lookup ?

Elle me parait beaucoup plus lourde,

A quel point de vue ?

moins lisible,

Ah bon ? Tu trouve plus lisible deux fonctions (get/set, on va faire
l'impasse sur del pour le moment) bourrées de if/elif/.... ? les
properties permettent (entre autres) de factoriser cette duplication.

moins
facile à comprendre et à maintenir.

Mon expérience (pour avoir pas mal utilisé __getattr__/__setattr__
avant que les properties n'existent) est que c'est au contraire bien
plus lisible et maintenable.

J'imagine qu'une fois qu'on est habitué, ça parait naturel.

L'intervention de NicolasP est
d'ailleurs assez révélatrice.

Révélatrice de sa non connaissance des décorateurs, des properties, et
de apply.

Oui, mais à mon avis c'est à prendre en compte. Tu te rends compte du nombre
de notions que tu convoques juste pour faire ça. Perso, j'ai quelques mois
d'expérience de dev Python à plein temps, avec des programmes en production
qui tournent 24h/24 et qui font ce qu'on leur demande. Même si j'ai bien
conscience d'en ignorer beaucoup sur des aspects plus ou moins avancés du
langage, j'ai pas non plus l'impression d'être un débutant complet. Et bien
tu vois, transformer un attribut en valeur calculée, je savais pas faire,
en tout cas pas comme il faut visiblement.

Avec Ruby, ça faisait pas une demi heure que j'avais commencé le tutorial
que je savais faire. Et pas besoin d'apprendre les décorateurs, les
descripteurs, les properties, de coder des fonctions imbriquées, etc. Juste
une syntaxe limpide, immédiatement compréhensible. Il y a un vieux précepte
qui dit qu'un langage devrait rendre faciles les choses simples et possible
les choses compliquées.

Tu ne comprends pas, donc tu dénigres, en somme ?

Pas du tout, bien au contraire.

Bien au contraire ???

Oui, je suis plutôt admiratif. Mon couplet sur les obfuscateurs Python
mangeurs d'enfants se voulait plus humoristique qu'autre chose.

On 1 mar, 04:17, Alex Marandon <a...@invalid-address.org> wrote:

bruno.desthuilli...@gmail.com wrote:

On 28 fév, 10:44, Alex Marandon <a...@invalid.org> wrote:

bruno.desthuilli...@gmail.com wrote:

Au final, je pense que je vais garder ma solution a base de
__getattr__, nettement plus lisible, a mon tres subjectif avis.

Dommage pour toi - et pour ceux qui devront maintenir ton code.

Pourquoi ? Quels sont les avantages de la solution utilisant le protoc ole
descripteur ?

(nb : en l'occurence sous la forme de properties, ce qui n'est qu'une
des applications de ce protocole)

Un premier avantage est que la gestion des accès (get/set/del) est
regroupée par propriété, pas par type d'accès (on voit donc tou tes les
'règles' d'une propriété en un même endroit). Un second avantag e est
qu'il n'y a pas besoin de toucher __getattr__, __setattr__ etc à
chaque modif (donc moins de risque de casser autre chose au passage).

Ok, mais si tu ajoutes plusieurs propriétés, tu dois copier toute la
plomberie ?

Non, j'ímagine tu peux factoriser ça...

Si tu utilise des properties, il faut effectivement définir à chaque
fois les accesseurs, et instancier une property avec. Avec la syntaxe
que j'emploie, c'est AMHA suffisament light pour ne pas être un frein
(personnellement, je trouve ça moins lourd que de redéfinir get/
setattr). Si tu utilise des descripteurs perso, c'est généralement
plus simple, puisque le traitement est déjà dans le descripteur. Il y
a donc une factorisation possible quand tu a plusieurs properties qui
fonctionne de la même façon -> extraction vers un descripteur.

Un quatrième avantage est que la
property (ou autre descripteur) apparait dans le listing des attributs
de l'objet (et peut avoir une docstring).

Ah effectivement ça, ça me parle, tu m'as convaincu.

Un cinquième avantage est
que ça évite de devoir modifier les règles de lookup par défaut si on
n'en a pas le besoin. Un sixième avantage est que ça permet de
modifier les règles de lookup si besoin est sans mélanger ça avec les
définitions des properties.

C'est quoi, les règles de lookup ?

Résolution de nom. Quand tu tape:

unObjet.unAttribut

ou

unObjet.unAttribut = uneValeur

Python doit "résoudre" le nom "unAttribut" dans le contexte de
"unObjet". Cette résolution se fait selon certaines règles, qui
impliquent entre autres les attributs d'instance, les attributs de
classe, les attributs des classes parentes, et les descripteurs. Et la
présence de __getattribute__, __getattr__ et __setattr__, of course.

Elle me parait beaucoup plus lourde,

A quel point de vue ?

moins lisible,

Ah bon ? Tu trouve plus lisible deux fonctions (get/set, on va faire
l'impasse sur del pour le moment) bourrées de if/elif/.... ? les
properties permettent (entre autres) de factoriser cette duplication.

moins
facile à comprendre et à maintenir.

Mon expérience (pour avoir pas mal utilisé __getattr__/__setattr__
avant que les properties n'existent) est que c'est au contraire bien
plus lisible et maintenable.

J'imagine qu'une fois qu'on est habitué, ça parait naturel.

Tout à fait.

L'intervention de NicolasP est
d'ailleurs assez révélatrice.

Révélatrice de sa non connaissance des décorateurs, des propertie s, et
de apply.

Oui, mais à mon avis c'est à prendre en compte. Tu te rends compte du nombre
de notions que tu convoques juste pour faire ça.

Non. Mais je ne pense pas qu'il y en ait tant que ça...
Essentiellement :
- la notion de "décorateur" : rien de plus qu'un peu de sucre
syntaxique sur une fonction d'ordre supérieur. Pas de quoi fouetter un
chat.
- le protocole descripteur et les règles de résolution de nom (ça va
ensemble) : ça fait quand même parties des notions de base dans un
langage, non ?

Perso, j'ai quelques mois
d'expérience de dev Python à plein temps, avec des programmes en prod uction
qui tournent 24h/24 et qui font ce qu'on leur demande. Même si j'ai bien
conscience d'en ignorer beaucoup sur des aspects plus ou moins avancés du
langage, j'ai pas non plus l'impression d'être un débutant complet. E t bien
tu vois, transformer un attribut en valeur calculée, je savais pas fair e,
en tout cas pas comme il faut visiblement.

C'est pourtant abondamment documenté. Tu sais, je n'ai pas inventé ça
moi-même...

Avec Ruby, ça faisait pas une demi heure que j'avais commencé le tuto rial
que je savais faire.

Et pas besoin d'apprendre les décorateurs, les
descripteurs, les properties, de coder des fonctions imbriquées, etc. J uste
une syntaxe limpide, immédiatement compréhensible. Il y a un vieux pr écepte
qui dit qu'un langage devrait rendre faciles les choses simples

Facile:

class Toto(object):
def setfoo(self, foo):
self._foo = foo.lower()
def getfoo(self):
return self._foo
foo = property(fget=getfoo, fset=setfoo)

je reconnais que c'est un tout petit peu plus verbeux que Ruby. Mais
bon : pas de décorateur, pas de fonction imbriquée, et même pas besoin
de comprendre comment ça marche. Ca te va ?

La syntaxe que j'utilise (et qu'on peut utiliser sans la comprendre)
me plait davantage parce qu'elle:
- regroupe plus clairement les 'composants' de la property
- garde l'espace de nom de la classe propre (les accesseurs ne sont
pas exposés)

et possible
les choses compliquées.

Puis-je te recommander le code source de FormEncode, et
particulièrement de l'API "Declarative" ?-)

Tu ne comprends pas, donc tu dénigres, en somme ?

Pas du tout, bien au contraire.

Bien au contraire ???

Oui, je suis plutôt admiratif. Mon couplet sur les obfuscateurs Python
mangeurs d'enfants se voulait plus humoristique qu'autre chose.

Désolé, je ne devais pas avoir manger ma dose quotidienne de
marmots !-)

Bonsoir,

Amaury Forgeot d'Arc wrote:

SoapPy, qui transforme naturellement des appels de fonction vers
XML-RPC;

SoapPy, c'est drolement bien choisi pour une lib XML-RPC.

Trop facile! SoapPy fait du Soap, et il me semble qu'il fait du XML-RPC
aussi. SOAP est-il une spécialisation de XML-RPC ?

wxPython qui permet de dériver en Python des objets C++;

En fait, c'est plutot l'inverse. Le fait qu'on puisse deriver des objets C++
en Python permet l'utilisation de toolkits graphiques comme Qt.

Mes remarques ne visent pas à promouvoir telle ou telle librairie, mais
bien ceci: en python, on peut dériver naturellement des objets C++. Et
ça marche pour de vrai.

py.test pour écrire des tests unitaires sans aucune librairie...

Et py.test, ce serait pas une librairie par hasard ? Ah, un certain Jacques
T. me souffle que ce serait une bibliotheque.

Ah, j'ai mal parlé: py.test permet d'écrire les tests unitaires sans
utiliser aucune fonction qui ne soit pas du python standard (même pas de
'import py.test').
py.test est plutôt un utilitaire, un script qui assemble du code python
"pur jus" en tests unitaires. Contrairement à JUnit et les autres qui
obligent à dériver telle ou telle classe, py.test utilise à fond la
"programmation orientée aspect", qui va beaucoup plus loin en python
qu'on ne sait le faire en Java, par exemple.
Du coup, les tests unitaires sont plus faciles à écrire, et sont donc
plus complets...

--
Amaury

bruno.desthuilliers@gmail.com wrote:

- la notion de "décorateur" : rien de plus qu'un peu de sucre
syntaxique sur une fonction d'ordre supérieur. Pas de quoi fouetter un
chat.
- le protocole descripteur et les règles de résolution de nom (ça va
ensemble) : ça fait quand même parties des notions de base dans un
langage, non ?

Si tu le dit...

tu vois, transformer un attribut en valeur calculée, je savais pas faire,
en tout cas pas comme il faut visiblement.

C'est pourtant abondamment documenté. Tu sais, je n'ai pas inventé ça
moi-même...

Ok, c'est vrai que j'ai toujours un peu de mal a m'y retrouver dans la
doc Python, le tutoriel est parfait pour debuter, mais insuffisant pour
programmer. Le reference est trop aride pour que je puisse en tirer
partie autrement qu'en tant que pense-bete pour des choses que j'ai deja
utilisees. Quand a la doc de la bibliotheque standard, elle suit
l'organisation de la bibliotheque standard elle-meme, selon une logique
qui me depasse souvent. Au final, je finis generalement par utiliser
google et pecher les infos par ci par la.

class Toto(object):
def setfoo(self, foo):
self._foo = foo.lower()
def getfoo(self):
return self._foo
foo = property(fget=getfoo, fset=setfoo)

je reconnais que c'est un tout petit peu plus verbeux que Ruby. Mais
bon : pas de décorateur, pas de fonction imbriquée, et même pas besoin
de comprendre comment ça marche. Ca te va ?

Oui, je prefere. D'un autre cote, Ruby est plus verbeux en l'absence de
valeurs calculees puisqu'il faut une ligne de declaration des accesseurs.

et possible
les choses compliquées.

Puis-je te recommander le code source de FormEncode, et
particulièrement de l'API "Declarative" ?-)

Effectivement, c'est a l'air bien complique :)

bruno.desthuilliers@gmail.com wrote:

(snip)

tu vois, transformer un attribut en valeur calculée, je savais pas faire,
en tout cas pas comme il faut visiblement.

C'est pourtant abondamment documenté. Tu sais, je n'ai pas inventé ça
moi-même...

Ok, c'est vrai que j'ai toujours un peu de mal a m'y retrouver dans la
doc Python, le tutoriel est parfait pour debuter, mais insuffisant pour
programmer. Le reference est trop aride pour que je puisse en tirer
partie autrement qu'en tant que pense-bete pour des choses que j'ai deja
utilisees. Quand a la doc de la bibliotheque standard, elle suit
l'organisation de la bibliotheque standard elle-meme, selon une logique
qui me depasse souvent. Au final, je finis generalement par utiliser
google et pecher les infos par ci par la.

C'est vrai que l'organisation de la doc est un peu partie en vrille avec
le temps. Il faut lire les peps, les what's new, et la doc des
descripteurs et des métaclasses... Ca mériterais un petit peu de rangement.

class Toto(object):
def setfoo(self, foo):
self._foo = foo.lower()
def getfoo(self):
return self._foo
foo = property(fget=getfoo, fset=setfoo)

je reconnais que c'est un tout petit peu plus verbeux que Ruby. Mais
bon : pas de décorateur, pas de fonction imbriquée, et même pas besoin
de comprendre comment ça marche. Ca te va ?

Oui, je prefere. D'un autre cote, Ruby est plus verbeux en l'absence de
valeurs calculees puisqu'il faut une ligne de declaration des accesseurs.

Comme quoi... 1 partout, la balle au centre !-)

et possible
les choses compliquées.

Puis-je te recommander le code source de FormEncode, et
particulièrement de l'API "Declarative" ?-)

Effectivement, c'est a l'air bien complique :)

En même temps, c'est très instructif. Le fait justement d'exposer une
bonne partie de son implémentation est un des points forts de Python. Ca
permet de prendre la main sur des aspects qui, dans pas mal d'autres
langages, sont totalement opaques.