Making command-line args available to deeply-nested functions

[Loris Bennett]

George Fischhof <george at fischhof.hu> writes:

> Loris Bennett <loris.bennett at fu-berlin.de> ezt írta (időpont: 2021. aug.
> 20., P 17:54):
>
>> Julio Di Egidio <julio at diegidio.name> writes:
>>
>> > On Friday, 20 August 2021 at 11:54:00 UTC+2, Loris Bennett wrote:
>> >> Hi,
>> >>
>> >> TL;DR:
>> >>
>> >> If I have a command-line argument for a program, what is the best way
>> >> of making this available to a deeply-nested[1] function call without
>> >> passing the parameter through every intermediate function?
>> >
>> > To not pass arguments you need shared state ("global variables"): and
>> > options in shard state, unless you have very good reasons to do
>> > otherwise, is simply a no no.
>>
>> Doesn't that slightly depend on the size of your "globe"?  If a program
>> does a few, in some sense unrelated things, and, say, only runs for a
>> few minutes, could you not decide to make a particular parameter global,
>> even though only one function needs it?  In general, however, I would
>> also avoid this.
>>
>> > <snip>
>> >> I can see that the top-level could just create an object from a class
>> >> which encapsulates everything, but what if I want to keep the salutation
>> >> generation separate, so that I can have a separate program which just
>> >> generates the salutation and print it to the terminal?
>> >
>> > Yes, that's basically the way to go: parse arguments into a structure (an
>> > object) that contains all options/parameters then pass that down.  Next
>> level:
>> > some sections of your code may require a certain subset of those
>> options, some
>> > may require some other, so you would structure your options object in
>> > sub-objects for the various sets of correlated options, then rather pass
>> just
>> > the sub-object(s) that are relevant to the section of code you are
>> calling.
>> > Variations are of course possible, anyway that's the basic idea.
>> >
>> > Also have a look at the "argparse" library, it does all the heavy
>> lifting for
>> > the parsing and creation of those objects, definitely advised for in non
>> trivial
>> > cases: <https://docs.python.org/3/library/argparse.html>.
>>
>> I am already using 'argparse' ('configargparse' actually).  What aspect
>> should I be looking at in order to produce "sub-objects"?
>>
>> >> I guess I am really asking how to avoid "passing through" arguments to
>> >> functions which only need them to call other functions, so maybe the
>> >> answer is just to avoid nesting.
>> >
>> > No, you don't get rid of code structure just not to pass arguments to
>> > a function...  Code may be poorly structured, but that's another
>> > story.
>>
>> As I am writing new code it is more a question of imposing structure,
>> rather than getting rid of structure.  Unwritten code for a given
>> purpose obviously has some sort of structure with regards to, say, loops
>> and conditions, but I am less sure about the implications for how the
>> code should be nested.  Another argument against deeply-nested functions
>> is the increased complexity of testing.

[snip (15 lines)]>

> Hi,
>
> Also you can give a try to click and / or  typer packages.
> Putting args into environment variables can be a solution too
> All of these depends on several things: personal preferences, colleagues /
> firm standards, the program, readability, variable accessibility (IDE
> support, auto completition) (env vars not supported by IDEs as they are not
> part of code)

Thanks for the pointers, although I have only just got my head around
argparse/configargparse, so click is something I might have a look at
for future project.

However, the question of how to parse the arguments is somewhat separate
from that of how to pass (or not pass) the arguments around within a
program.

Cheers,

Loris

-- 
This signature is currently under construction.