Clean up imports of old modules#433
Conversation
acolomb
left a comment
acolomb
left a comment
There was a problem hiding this comment.
Looks good, but I'd like some discussion / reasoning about using absolute imports within the same package. DRY tells us to leave out the package name in places within the same package, and I've seen very few use cases where relative imports don't work.
|
|
||
| # Compatibility | ||
| from .base import Variable | ||
| from canopen.pdo.base import Variable |
There was a problem hiding this comment.
Why change to absolute package reference here? I'd actually rather go the other way and use relative imports within the same package. Maybe it's a matter of taste, but I liked the old style.
There was a problem hiding this comment.
No other reason that PEP 8 recommends using absolute imports, so it's become a habit for many projects. PEP 8 also states "explicit relative imports are an acceptable alternative to absolute imports, especially when dealing with complex package layouts where using absolute imports would be unnecessarily verbose". So either is acceptable, but with preference to the former. And lastly, the rest of canopen is using absolute imports. I find it messy that the import styles are mixed.
|
|
||
| # Compatibility | ||
| from .base import Variable, Record, Array | ||
| from canopen.sdo.base import Variable, Record, Array |
2 participants
The canopen package have import leftovers from earlier versions of Python. This PR cleans up the no longer valid imports.
import Queuedates to py 2import collections.*Mappingwas changed tocollections.abc.*Mappingin py 3.3import ConfigParserdates to py 2import xml.etree.cElementTreeis deprecated since py 3.3. It will pick the fastest option when usingxml.etree.ElementTree.baseintocanopen.pdo.basein canopen/pdo/init.py.baseintocanopen.sdo.basein canopen/sdo/init.py