How about some syntactic sugar for " __name__ == '__main__' "?
cs at zip.com.au
Thu Nov 13 09:47:25 CET 2014
On 13Nov2014 19:04, Chris Angelico <rosuav at gmail.com> wrote:
>On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson <cs at zip.com.au> wrote:
>> Indeed. This aspect is a deal breaker for me; I'd never use it.
>> I make a point of putting the module's main function right up the top,
>> immediately after the imports and any "constants" (let's not dither over
>> that term). I _want_ the main function to in the reader's face when they
>> visit the module code. All the cogs come later.
>> And lots of my modules have "main" functions. Terribly useful.
>Hmm, I go the other way. As much as possible, I prefer functions to
>call what's above them, not what's below them - so the main function
>would always be at the end of the file. [...]
My view is that if there's a main (i.e. the module implements a small app all
on its own, however tiny), then the main program logic should come first. The
details follow later.
For a pureply functional module (utility functions, classes built on them, etc)
I tend to go your way. But the main, if there is one, comes first.
>The very top of the file
>should have comments/docstrings etc, then imports, then pure utility
>functions that don't call on anything else, then "guts" functions, and
>finally routines that are called externally but never internally (like
>main). That way, if you're wondering at what some name means, you go
>to the top of the file and find the first occurrence; that'll usually
>be its definition.
Sounds effective. I probably prefer my code (main aside, again) organised the
same way. Needless to say, I have a heap of modules that could do with a
cleanup along these lines.
Cameron Simpson <cs at zip.com.au>
If you make people think they're thinking, they'll love you; but if you
really make them think, they'll hate you. - Don Marquis
More information about the Python-list