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