Loris Bennett <loris.benn...@fu-berlin.de> ezt írta (időpont: 2021. aug. 23., H 19:26):
> George Fischhof <geo...@fischhof.hu> writes: > > > Loris Bennett <loris.benn...@fu-berlin.de> ezt írta (időpont: 2021. aug. > > 20., P 17:54): > > > >> Julio Di Egidio <ju...@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 -- https://mail.python.org/mailman/listinfo/python-list