Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #90485

Re: Python file structure

Newsgroups comp.lang.python
Date 2015-05-12 12:58 -0700
References <f25aa9d4-4025-457d-8072-5327c98db1bd@googlegroups.com> <026e6357-917c-4d50-b70f-70903aa0e065@googlegroups.com>
Message-ID <05daad5f-b728-48ee-bf06-5e7374df936d@googlegroups.com> (permalink)
Subject Re: Python file structure
From zljubisicmob@gmail.com

Show all headers | View raw


On Tuesday, May 12, 2015 at 9:49:20 PM UTC+2, Ned Batchelder wrote:
> On Tuesday, May 12, 2015 at 3:13:32 PM UTC-4, zljubi...@gmail.com wrote:
> > Hi, I have python file with the following structure:
> > 
> > import...
> > 
> > A = configparser.get(...) 
> > B = configparser.get(...)
> > 
> > Command line parameters parsing [they can change variable A or B]
> > 
> > Def usage()
> > 	Print how to use script parameters
> > 
> > def main():
> > 	...
> > 
> > if __name__ == "__main__":
> >     main()
> > 
> > If I find an error in command line parameters section I cannot call function usage() because it is not defined yet. 
> > 
> > I have few options here:
> > 1.	Put definition of usage function before command line parameters parsing section
> > 2.	Make parameters global and put them in the main function
> > 3.	...maybe some other options...
> > 
> 
> I would put all of the code into a function some place.  Don't have
> anything at the top level of the file except imports, function (and
> class) definitions, and an "if __name__....." clause at the bottom.
> 
> If you need to use globals, assign them inside a parse_arguments
> function that has a "global" statement in it.
> 
> This advice is consistent with Chris' "define things before they
> are used."  It does it by defining everything before anything is
> run.
> 
> As a side note, if you are going to have code at the top-level of
> the file, then there's no point in the "if __name__..." clause.
> That clause is designed to make a file both runnable and importable.
> But your top-level code makes the file very difficult to import.
> 
> --Ned.

It makes sense. The only drawback is that variables are global so they could be changed anywhere in the program.
I also agree that it is more python approach.

Thanks to both of you.

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Python file structure zljubisicmob@gmail.com - 2015-05-12 12:13 -0700
  Re: Python file structure Chris Angelico <rosuav@gmail.com> - 2015-05-13 05:29 +1000
  Re: Python file structure Ned Batchelder <ned@nedbatchelder.com> - 2015-05-12 12:49 -0700
    Re: Python file structure zljubisicmob@gmail.com - 2015-05-12 12:58 -0700
      Re: Python file structure Dave Angel <davea@davea.name> - 2015-05-12 16:43 -0400
    Re: Python file structure Chris Angelico <rosuav@gmail.com> - 2015-05-13 06:02 +1000
    Re: Python file structure Terry Reedy <tjreedy@udel.edu> - 2015-05-12 17:34 -0400
  Re: Python file structure Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-12 13:54 -0600
  Re: Python file structure Chris Angelico <rosuav@gmail.com> - 2015-05-13 06:07 +1000
  Re: Python file structure Tim Chase <python.list@tim.thechases.com> - 2015-05-13 13:34 -0500
  Re: Python file structure Chris Angelico <rosuav@gmail.com> - 2015-05-14 12:03 +1000

csiph-web