3

Is it seen as bad practice to try to hide local functions in Python? The intention not to clutter the global namespace with second rank or common function names may stand against ... er... some Pythonisms that I am not aware of.

def foo(aparameter):
     def somenamewhichislikelytoclash(anotherparam):
         ....

Is there a runtime penalty? AFAIK all functions contexts are created on the heap anyway, so binding and destroying would take just as much time for locals - is there more?

I am asking this for the Python context specifically, as I know enough about separation of concerns, clean keeping of namespace etc. in other languages.

Improve this question
  • 1
    If this very somenamewhichislikelytoclash function is only used within foo, and is indeed likely to clash its name with some other function within the same module, a closure makes perfect sense. – Richard Neumann Dec 7 '17 at 16:56
  • 1
    It probably depends on the context, but either that function is not bound to a class and only clutters the module in which it is defined, so it's not too bad, or it is bound to a class and then will not clutter the global namespace. The only situation I can see which would be a problem is if you import everything from a module (from module import *), but this is a bad practice in itself, so let's ignore that. – Vincent Savard Dec 7 '17 at 16:59
  • If it's actually a problem in the module in which the function is defined, then I would first ask myself if this module is too big, or if the function can be renamed to something which won't clash with another function. – Vincent Savard Dec 7 '17 at 17:01
  • @VincentSavard my question stems from writing some combinatorial functions which tend to profit from helper functions like stepix etc. where no two stepping functions tend to be identical. – Vroomfondel Dec 7 '17 at 20:39
  • 2
    Possible duplicate of Should I place functions that are only used in one other function, within that function? – Karl Bielefeldt Dec 7 '17 at 21:47
3

Hiding/shadowing like this is generally a bad idea from a code maintenance perspective. Unless the location of definition is very near its use (so a programmer can keep both definition and use in the same visual context) then it's too easy to get confused. Even then, re-factoring and other code maintenance could wash the definition downstream and then definition and use may not be near one another.

There are very few scenarios where you need/want to reuse a function name unless you are overriding previously defined functionality and, in that case, you should probably be introducing some object/class structure to accommodate this behavior.

Improve this answer
  • I see your points. The motivation to ask came from a very different scenario, though - I was writing some combinatorial functions which become so much more tidied up if you introduce small helper functions, e.g. stepping an array of indices from 0 to maximum in a very specific way. I can't come up with any more clever names than stepix or the like, and if you have a number of algorithms then there are more functions which need to step an index - but I think my question is sufficiently answered. Thanks. – Vroomfondel Dec 7 '17 at 20:35
  • I think a scenario where you are reusing small helper functions that are pretty specific to that scope your working in, its a pretty reasonable use case for name hiding. Jim brings up a good point about how it could be problematic for maintenance/ readability, but I think in your use case its a good fit and could improve readability. – Zv_oDD Jan 25 '19 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.