Making command-line args available to deeply-nested functions

[George Fischhof]

Loris Bennett <loris.bennett at fu-berlin.de> ezt írta (időpont: 2021. aug.
23., H 19:26):

> 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.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

>
>
>



Hi,
I thought not just parsing, but the usage method: you add a decorator to
the function where you want to use the parameters. This way you do not have
to pass the value through the calling hierarchy.

Note: typer is a newer package, it contains click and leverages command
line parsing even more.


BR,
George