DIRAC
DIRAC copied to clipboard
DIRACGrid
DIRAC modules with same name as system modules
Would it be possible to get rid of the Dirac modules that "replace" the system modules just with a difference in the fact that names are capitalized... It is a real pain, for example when the disk on which Dirac is is mounted with case-insensitive namespace... Very likely most of them should just be removed and replaced by the python native ones (e.g. Time that mainly replaces datetime.py and not time.py) More generally a review of the obsolete or almost useless modules that may have had an interest with python 2.1 should be made and replaced by the current python native implementation...
Can you make more specific suggestion about which modules you think must be dropped. Also I do not understand how DIRAC modules with the same names as system ones modulo capitalization can be an issue: you do not import them the same way as system modules but by giving there full package path. So, what is the real practical problem ?
Hi Andrei, They are not imported like import Os import Time but as there are many import os import time whenever there is a problem of case sensitivity in the file system, the Dirac module is imported, which is really weird and leads to a lot of errors. Of course the file system should not be case insensitive, but this happens from time to tim… More generally I think it is not good practice to have modules with the same name but just different cases and also different purposes (the worse being Time.py which is a Dirac implementation of date time and not of time). In most case I think we could get rid of those two modules and just use native python modules. My 2 cents, Philippe
Le 21 déc. 2014 à 14:09, Andrei Tsaregorodtsev [email protected] a écrit :
Can you make more specific suggestion about which modules you think must be dropped. Also I do not understand how DIRAC modules with the same names as system ones modulo capitalization can be an issue: you do not import them the same way as system modules but by giving there full package path. So, what is the real practical problem ?
— Reply to this email directly or view it on GitHub.
Dr Philippe Charpentier J09210, Physics Department, CERN, CH-1211 Genève 23 LHCb Experiment Distributed Computing Coordinator Office 2-R-007, Tel : +41 22 767 4244 , GSM : +41 76 487 0167 mailto:[email protected] http://cern.ch/Philippe.Charpentier
Discussed briefly at today's BiLD meeting (!!).
- see if they can be ditched
- add deprecation warnings to the old names
- change names
From v7r2 the names should be less of a problem as from __future__ import absolute_imports is used everywhere to get Python 3 style imports. This then means you need to use from . import Time instead of import Time.
That said, the majority of this code can probably be dropped in v7r3 (after adding deprecation notices to v7r2).
