Oct-15-2020, 05:51 PM
Thanks for taking the time to review ^-^!
I agree that someone could definitely shoot themselves in the foot with this thing, and probably isn't a great tool to give to a beginner. Because of the work that I put into limiting the recursion scope, and the way you have to name the thing you're looking for, I think it would be safe in 99.99% of cases. Even with that certainty though I don't believe it would be appropriate to depend on this in a redistributed package.
I have found 2 production use cases that I think it's essential for though. The first is ipython notebooks, because notebooks are designed to be a container for things like stock ideas. The natural tendency is to want to organize them with a meandering nested folder structure because that's kinda just how ideas work. But notebooks often need to import a central module from the repo they live in. Here is an example where the author expects you to copy the notebook files out of the nb folder, and up one directory before you can begin using them:
https://github.com/rsvp/fecon235
I've corrected this so that the notebooks can run in place without requiring the user to do any reorganizing, by adding:
from FooFinder import fecon235
Here's the corrected fork:
https://github.com/MadisonAster/fecon235
The 2nd use case that I've run into professionally, has been in building software pipelines. Often a module depends on some central module that imports it, but that module also needs to sometimes be run as __main__ by some other outside program. "from FooFinder import CentralModule" cures this.
My "code garden" project also depends on it. It's a permanently experimental project that I've been tinkering with to provide a general connectivity framework between various languages and tools. I'm trying to make the modules 100% modular, for recyclability purposes. Tests live with the code, and the modules depend on each other relatively. Example:
https://github.com/MadisonAster/KungFu/b...Cluster.py
https://github.com/MadisonAster/KungFu/b...Cluster.py
I agree that someone could definitely shoot themselves in the foot with this thing, and probably isn't a great tool to give to a beginner. Because of the work that I put into limiting the recursion scope, and the way you have to name the thing you're looking for, I think it would be safe in 99.99% of cases. Even with that certainty though I don't believe it would be appropriate to depend on this in a redistributed package.
I have found 2 production use cases that I think it's essential for though. The first is ipython notebooks, because notebooks are designed to be a container for things like stock ideas. The natural tendency is to want to organize them with a meandering nested folder structure because that's kinda just how ideas work. But notebooks often need to import a central module from the repo they live in. Here is an example where the author expects you to copy the notebook files out of the nb folder, and up one directory before you can begin using them:
https://github.com/rsvp/fecon235
I've corrected this so that the notebooks can run in place without requiring the user to do any reorganizing, by adding:
from FooFinder import fecon235
Here's the corrected fork:
https://github.com/MadisonAster/fecon235
The 2nd use case that I've run into professionally, has been in building software pipelines. Often a module depends on some central module that imports it, but that module also needs to sometimes be run as __main__ by some other outside program. "from FooFinder import CentralModule" cures this.
My "code garden" project also depends on it. It's a permanently experimental project that I've been tinkering with to provide a general connectivity framework between various languages and tools. I'm trying to make the modules 100% modular, for recyclability purposes. Tests live with the code, and the modules depend on each other relatively. Example:
https://github.com/MadisonAster/KungFu/b...Cluster.py
https://github.com/MadisonAster/KungFu/b...Cluster.py