Le 9 septembre 2009 18:00,
<address@hidden> a écrit :
Send Tsp-devel mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nongnu.org/mailman/listinfo/tsp-devel
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tsp-devel digest..."
Today's Topics:
1. DTest name property problem with python2.6 (lionel duroyon)
2. Re: DTest name property problem with python2.6 (Eric Noulard)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 Sep 2009 19:42:42 +0200
From: lionel duroyon <address@hidden>
Subject: [Tsp-devel] DTest name property problem with python2.6
To: address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Bonjour à tous,
vous trouverez ci-dessous la reprise des messages précédents concernant ce
bug :
> après l'installation , j'ai lancé dtest-autotest et je suis tombé sur ce
que
> je pense être un bug :
>
[...]
> self.getName()
> RuntimeError: maximum recursion depth exceeded
>
> avec donc dtester qui appelle la méthode getName() de Thread et Thread qui
> appelle __getName() de dtester.
> Pour résoudre ce bug (si s'en est un), je propose de supprimer les
méthodes
>
> def __getName(self):
> return self.getName()
>
> name = property(fget=__getName)
>>Le problème est qu'en Python 2.5 ça fonctionne.
>>Peut-être peux-tu "seulement" supprimer __getName dans DTester
>> et remplacer
>>name = property(fget=__getName)
>>par
>>name = property(fget=Thread.getName)
> de dtester, en laissant ainsi à la classe Thread l'entière responsabilité
de
> la property name.
>>j'en pense que la property "name" ne doit pas être définie dans Thread
>>mais c'est à vérifier en python 2.6
en python 2.6, la classe threading définie bien la property name
contrairement à python 2.5,
il serait donc peut-être plus cohérent de laisser threading gérer cette
property et donc de la supprimer
en plus de __getName de dtester.py ?
autre question, est-ce qu'il est souhaitable de garder dtest en 2.5 ou bien
est-il amené à migrer à terme vers du python 3 ?
Merci d'avance.
--
Lionel Duroyon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gnu.org/pipermail/tsp-devel/attachments/20090908/af2b7ea0/attachment.html
------------------------------
Message: 2
Date: Tue, 8 Sep 2009 20:19:56 +0200
From: Eric Noulard <address@hidden>
Subject: Re: [Tsp-devel] DTest name property problem with python2.6
To: Transport Sample Protocol development list <address@hidden>
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Le 8 septembre 2009 19:42, lionel duroyon<address@hidden> a écrit :
> Bonjour à tous,
>
> vous trouverez ci-dessous la reprise des messages précédents concernant ce
> bug :
En fait y'a eu un petite erreur de tracker, le bug a terminé dans le
tracker de tasks:
https://savannah.nongnu.org/task/?9683
>>>j'en pense que la property "name" ne doit pas être définie dans Thread
>>>mais c'est à vérifier en python 2.6
>
> en python 2.6, la classe threading définie bien la property name
> contrairement à python 2.5,
OK.
> il serait donc peut-être plus cohérent de laisser threading gérer cette
> property et donc de la supprimer
>
> en plus de __getName de dtester.py ?
C'est mieux mais ça doit marcher en 2.5 et en 2.6,
car il reste encore pas mal de python 2.4,2.5. en circulation.
On doit pouvoir définir le getter que si il n'est pas déjà défini.
par exemple avec
un
if "name" in threading.Thread.__dict__
y'a peut-être plus propre en faisant de l'introspection.
> autre question, est-ce qu'il est souhaitable de garder dtest en 2.5 ou bien
> est-il amené à migrer à terme vers du python 3 ?
Je dirais qu'on peut tenter d'être compatible 3.0 (on l'est peut-être
déjà d'ailleurs)
mais surtout pas migrer en 3.0 au risque d'être incompatible 2.[56].*
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
------------------------------
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel
End of Tsp-devel Digest, Vol 71, Issue 1
****************************************