upm
upm copied to clipboard
python upm module location/names
Python modules have been moved to a upm/ subdir which is pretty nice actually, but why has the pyupm_ prefix been retained? That seems complete overkill and would make it much nicer to do:
from upm import i2clcd as lcd
instead of
from upm import pyupm_i2clcd as lcd
Hi all, I second this proposal :-)
I concur.
The pyupm_ portion of this has always bugged me but I'm not sure of the historical significance there. I assume 'upm' was originally used to designate the UPM python modules, and the extra 'py' prefix was there to let users know that it's a python module in case they didn't see the extension ??? The node/java modules have similar filenames. I would also like to clean up the import X as Y syntax. It's valid, but seems to be abused/overused in the UPM repo IMO.
Example: from upm import pyupm_my9221 as upmGroveCircularLED
Can simply be: from upm import my9221 or import upm.my9221
A question I have: Can the same be done w/node and java modules?
lib/java/upm_t8100.jar vs. lib/java/upm/t8100.jar
and
lib/node_modules/jsupm_t8100/jsupm_t8100.node vs lib/node_modules/upm/t8100.node
This naming pre-dates my involvement with this project, but I think doing this where possible would be a nice improvement. Of course it would be an "API" change though right? With all that might entail...
Correct. This would affect all the SWIG module usage. The xxxupm_ strings are everywhere in the UPM repo: CMakeLists.txt SWIG .i files Examples etc...
It would be nice to see more uniform usage throughout. Cmake targets could also benefit from a renaming to simplify the build environment.
Example target names for dfrph (current): _pyupm_dfrph-python3 _pyupm_dfrph-python2 javaupm_dfrph dfrph dfrph-c jsupm_dfrph
Could be: dfrph-c dfrph-cxx dfrph-java dfrph-node dfrph-python2 dfrph-python3
dfrph-c dfrph-cxx dfrph-java dfrph-node dfrph-python2 dfrph-python3
Yes, I like that.
We could also rename the driver interface files -
jsupm_mma7660.i -> javascript.i javaupm_mma7660.i -> java.i pyupm_mma7660 -> python.i
In the driver dirs too.
I think these are all good changes and I agree with them. However, time constraints will prevent us from being able to integrate and test them for the upcoming 1.0 tag. We can go down this route after our next stable release.