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


Groups > comp.lang.python > #90484

Re: Python file structure

References <f25aa9d4-4025-457d-8072-5327c98db1bd@googlegroups.com> <CAPTjJmrtLoCGOAr+F1Q7zgzv3hUhvrVA3ADdaLe9mP9YSShi6Q@mail.gmail.com>
From Ian Kelly <ian.g.kelly@gmail.com>
Date 2015-05-12 13:54 -0600
Subject Re: Python file structure
Newsgroups comp.lang.python
Message-ID <mailman.411.1431460510.12865.python-list@python.org> (permalink)

Show all headers | View raw


On Tue, May 12, 2015 at 1:29 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, May 13, 2015 at 5:13 AM,  <zljubisicmob@gmail.com> wrote:
>> 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
>
> I'd do this, unless there's a good reason not to. A simple usage
> function probably doesn't have many dependencies, so it can logically
> go high in the code. As a general rule, I like to organize code such
> that things are defined higher up than they're used; it's not strictly
> necessary (if they're used inside functions, the requirement is only
> that they be defined before the function's called), but it helps with
> clarity. That generally means that "def usage():" wants to go up above
> any place where "usage()" occurs, but below the definitions of any
> functions that usage() itself calls, and below the first assignments
> to any global names it uses. It's not always possible, but when it is,
> it tends to produce an easy-to-navigate source file.

+1.

Also, I like to put command-line parsing inside the main function and
make that its *only* responsibility. The main function then calls the
real entry point of my script, which will be something more
specifically named. This also has the advantage that if some other
module needs to invoke my script, all it has to do is call the entry
point function which will be named something more suitable than
"main".

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