[Dcmlib] Python testing
Eric Boix
Eric.Boix at creatis.insa-lyon.fr
Mon May 17 15:35:41 CEST 2004
Quoting Mathieu Malaterre <mathieu.malaterre at kitware.com>:
> 1. SWIG me genere un fichier gdcm.py, mais les tests veulent importer
> 'gdcmPython'. Est-ce qu'on pourrait se mettre d'accord sur une
> convention de nom?
gdcm.py contient ce que SWIG appelle les shadow classes (i.e. la valeur
ajoute'e reproduisant par exemple la traduction de l'heritage des classes
C++ en classes python). gdcmPython/__init__.py (qui invoque gdcm.py) est
notre valeur ajoute'e, comme le positionnement de GDCM_DICT_PATH (en
fonction du mode operatoire i.e. mode pre-installation ou mode installe').
SWIG ne peut avoir aucune connaissance du besoin de disposer GDCM_DICT_PATH
et encore moins de savoir ce que doit valoir GDCM_DICT_PATH.
Je ne vois pas comment on pourrait eviter d'avoir ces deux fichiers...
> 2. A quoi sert gdcmVersion.py, est-ce qu'ilk faut qu'il soit dans un fichier
> a part ? J'ai dumper la ligne en entete de gdcmPython.py pour l'instant
C'est a Benoit qu'il faut poser la question, mais je crois bien que
c'etait juste pour des raisons de packaging. A mon sens il serait bien
meilleur d'avoir le numero de version en dur dans le source C++ et
de le recuperer a la volle'e dans Python (comme c'est fait dans VTK
par exemple). Cela ralonge un tout petit peu le processus de packaging,
mais c'est a mon avis la bonne facon de faire pour eviter un mismatch
(une discrepance en franc,ais ?) entre le numero de version des sources
C++ et le numero de version utilise' pour le packaging.
> 3. Les tests suppose que 'import os' a ete fais ? Pourquoi ? J'ai rajouter
> une ligne dans gdcmPython.py pour qu'il le fasse.
Les noms de fichiers dicoms testes sont reconstruits en fonction du
mode operatoire (pre-install, ou install) a partir de GDCM_TEST_DATA_PATH
[cf les lignes du genre fileName = os.path.join(GDCM_TEST_DATA_PATH, entry[0]) ]
Il est aussi necessaire de pouvoir butter les fichiers temporaires
cree' par la test suite ( os.unlink(TargetFileName) ).
gdcmPython.py n'a donc pas besoins de "import os". Par contre testSuite.py
en a lui besoin.
Je ne comprends pas bien pourquoi tu as eu besoin de la rajouter dans
gdcmPython.py: qu'est ce qui plantait ?
> 4. Pour le GDCM_DICT_PATH, est-ce que je peux faire un truc du genre:
>
> # override cmake value if specify in env var:
> try:
> os.environ["GDCM_DICT_PATH"]
> GDCM_DICT_PATH = os.environ["GDCM_DICT_PATH"]
> except KeyError:
> GDCM_DICT_PATH = $VALEUR_CMAKE
Oh, il me semble que cela doit etre une bonne ide'e. A vrai dire, je ne
vois pas quel pourrait etre l'inconvenient...
> 5. Je comprends pas l'interet des:
> gdcmGlobal = gdcm.gdcmGlobal
> gdcmDictSet = gdcm.gdcmDictSet
> gdcmDicomDir = gdcm.gdcmDicomDir
> gdcmHeader = gdcm.gdcmHeader
> gdcmHeaderHelper = gdcm.gdcmHeaderHelper
> gdcmFile = gdcm.gdcmFile
> ...
> C'est pourtant cool les namespaces, non ? Ca evite de tout polluer.
Mea maxima culpa. L'ide'e etait la suivante. Avec Swig j'ai choisi de
wrapper TOUTES les classes C++ de gdcm (cf gdcm/gdcmPython/gdcm.i).
L'avantage est que cela permets parfois de voir des erreurs du C++
(par exemple une fonction declare'e mais non definie fera planter
l'importation dynamique de [lib]gdcmPython.so via gdcm.py via gdcmPython).
L'incoveninent est que cela brise l'encaspulation de la librairie C++
en exposant en Python des classes qui n'ont pas vocation a etre utilise'e
par l'utilisateur final.
MAIS comme (cf ci-dessus) gdcmPython importe gdcm.py, il FALLAIT re-exporter
les classes necesssaires. Donc je me suis contente' de re-exporter juste
ce qui a vocation a etre dans l'API... Ceci explique les lignes que tu
mentionnes ci-dessus.
Par contre, le namespace n'est pas casse', puisque gdcmHeader (par exemple)
existe dans le namespace gdcmPython lors de l'importation. Ces lignes
sont presentes pour eviter l'effet de bord des shadow classes i.e. pour
eviter de devoir ecrire des choses du genre:
import gdcmPython
a = gdcmPython.gdcm.gdcmHeader()
ou meme
from gdcmPython import *
a = gdcm.gdcmHeader()
Si tu vois mieux, on est preneur !
> 8. Merci de tester et de me rapporter les erreurs, je promets cette fois
> ci je ne mordrais personne ;)
Meuh non, meuh non, tu ne mords pas. Vus tes horaires et l'energie que tu
deploies pour gdcm, c'est bien normal qu'une remonte'e epidermique de
notre ami Benoit t'ai fait reagir ! Surtout continue ! On va y arriver.
Frog.
More information about the Dcmlib
mailing list