[Dcmlib] Python testing

[Jean-Pierre Roux]

Eric Boix wrote:

>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 ?) 
>
"un écart", "une contradiction", don't you mean?

>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.
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>