search

jpercent / pygrametl

Automatically exported from code.google.com/p/pygrametl
BSD 2-Clause "Simplified" License
1 stars 1 forks source link

Renaming Step and namemapping have inconsistent behaviours #1

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I've noticed that several namemapping behaviours where implemented.

The RenamingStep uses source row names as keys
wheras SCDensure uses dimension names as keys.

Is there a reason for this ? To me, mapping has no direction.

don't you think having a consistent behaviour allover the code will help user 
code maintenance ?

Regards

Original issue reported on code.google.com by julien.c...@gmail.com on 6 Sep 2012 at 10:38

GoogleCodeExporter commented 9 years ago 
For most renamings and namemappings, the form (KEY, VALUE) means "The attribute 
KEY should get its value from VALUE".

For RenamingStep and renaming(...) the current behavior is different. Here 
(KEY, VALUE) means "rename KEY to VALUE". 

It would probably make more sense to have a common behavior.

Original comment by c...@cs.aau.dk on 10 Sep 2012 at 8:05

GoogleCodeExporter commented 9 years ago 
To remedy this issue, there are now (in r8) functions called renamefromto and 
renametofrom in __init__.py. For backwards compatibility, rename is an alias 
for renamefromto. Likewise, there are now steps called RenamingFromToStep and 
RenamingToFromStep in steps.py. RenamingStep is an alias for 
RenamingFromToStep.

Original comment by c...@cs.aau.dk on 15 Sep 2012 at 3:50