How about some syntactic sugar for " __name__ == '__main__' "?

[Cameron Simpson]

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.

Cheers,
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