search

DIRACGrid / DIRAC

DIRAC Grid
http://diracgrid.org
GNU General Public License v3.0
112 stars 174 forks source link

DIRAC modules with same name as system modules #2207

Closed phicharp closed 2 days ago

phicharp commented 9 years ago

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...

sposs commented 9 years ago

I fully agree with that.

atsareg commented 9 years ago

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 ?

phicharp commented 9 years ago

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 notifications@github.com 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:Philippe.Charpentier@cern.ch http://cern.ch/Philippe.Charpentier

fstagni commented 3 years ago

Discussed briefly at today's BiLD meeting (!!).

chrisburr commented 3 years ago

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).

phicharp commented 3 years ago

Hmmmm... happy to see that this 6 years old issue is being tackled! ;-)