Making command-line args available to deeply-nested functions

Loris Bennett loris.bennett at fu-berlin.de
Fri Aug 20 07:15:00 EDT 2021


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.

Cheers,

Loris

-- 
This signature is currently under construction.


More information about the Python-list mailing list