58 ms·
What are some good strategies for naming things that don’t trigger name shadowing? If I’m writing a library of, say, github functions for our team’s Wibble pro
by gorgoiler 4y ago
What are some good strategies for naming things that don’t trigger name shadowing?
If I’m writing a library of, say, github functions for our team’s Wibble project I want to put it in wibble.github but that then precludes importing the global github package.
wibble.githubutils? wibble.githubhelpers? wibble.githubwrapper?
It’s such a silly thing but I’ve never really settled on a best practice for this and wonder what others do.
- autoexec 4y agoAs long as Wibble was unique I think you'd be okay, but personally I've just been going with option #2 and at the start of every script I modify sys.path to move sys.path[0] to the end. I agree with wrobell that it's hacky and far from the ideal, but it works and it should keep me from running into nasty surprises later. Another idea I saw suggested someplace was to just keep every script or module you create in its own directory to limit the potential for conflicts.
- friendzis 4y agoName shadowing is not unique to python, it exists in every language with semantics allowing to access ancestor scope without fully qualifying the name. A lot of us have been bitten in C++ style languages where introduction of method-local identifier shadows object-local identifier not prefixed with `this`. Python name shadowing is a side of the same coin. I have limited experience with python so take my words with a grain of salt. A working strategy is to go sort of Java style and have local modules/packages/scripts in their own directory beside main script. This way any shadowing you do becomes explicit in code