placing module level statements into def

[michaelcollier]

I have my own flowchart GUI for C++ that I'm extending to python and have a question about python statements that exist at module level i.e. they are outside of a def statement.

#module level statements, simple example
print(123)

The flowchart tool can handle statements that exist within def (because it can already handle C++ statements between braces{}), so I'm considering automatically wrapping module level statements into a pre-named def called "initialization".

#module initialization, wrapping commands into a def
def initialization():
    print(123)
initialization()

I'm not sure about the kind of issues I would have if I automatically wrapped such statements. Can anyone with python experience suggest any issues that may occur if I took this approach? I can then look at how the python is reverse engineered into the GUI and handle any such issues..

Thanks in advance

[sparkz_alot]

We might need a clearer explanation, or at least expand it a bit.  The first thing is Python is not C++.  In your example, "print(123)" is not a "statement", it is a call to the builtin function "print()" with the argument of the integer "123".  If you are saying you would like to create a function that contains default values or performs the same thing every time it's called, then sure.  Unless you assign a variable(s), in which case they will only exist within "initialization" unless you use a "return" to send it to the outside world. I'm probably not explaining this well, but in my defense, I'm still on my first cup of coffee 

[michaelcollier]

Thanks sparkz_alot,

To clarify a bit more..

I only want the following statements at module level:

1. import
2. class
3. def
4. assignments ( a=xyz )

... Except for the __name__  /  __main__ test

5. if __name__ == "__main__":

 
What I definatley don't want at module level are things like:

6.  with
7.  while
8.  for
9.  pass
10. try
11. raise
12. function_call()
 
Can you see any technical reason why such a restriction would prevent doing things in python? I know it might not suit everyone...

[ichabod801]

I think you could work around just about anything with that restriction, but I think certain things might make the work around rather clunky. I try to follow that pattern, but I'm willing to break it when things get to clunky.

The first thing that comes to mind are complicated global constants. Sometimes you want a global constant that can't be created with a simple assignment. I will sometimes put that into a function, and assign the result of the function to the global constant, but that would seem to violate your rule #12.

The second thing that comes to mind is lengthy initialization. I had a poetry program that took a while to set up the word list, rhymes, and synonyms, so I would have a print statement at each point saying "Now initializing this part..." so the user knew why there was a delay.

[michaelcollier]

A quick thought on notifying module loading, this could be centralized?

# module "import_notify.py"
import time

is_enabled = True
def notify ( a_str ):
    if is_enabled:
      print ( "Loading @: " + time.asctime() + " " + "'" + a_str + "'" )
    return

#place at top of every module
import import_notify
import_notify.notify ( __name__ )

Loading @: Sun Apr 30 14:07:27 2017 '__main__'
Loading @: Sun Apr 30 14:07:27 2017 'import_files'
Loading @: Sun Apr 30 14:07:27 2017 'more_files'
Loading @: Sun Apr 30 14:07:27 2017 'even_more_files'

---

Sometimes you want a global constant that can't be created with a simple assignment. I will sometimes put that into a function, and assign the result of the function to the global constant, but that would seem to violate your rule #12.

Do you mean something like:

# "my_module.py"
def something_complex():
    return 1+3+4+5+6+7+8+9

global_const = something_complex()

That would be OK for my purposes, I just want to avoid calling something_complex() on its own.

[ichabod801]

I wouldn't centralize notifying, I rarely need to do it. But that is what I meant about using functions for complex constants.

[volcano63]

As far as complex constants go, I like to have string constants organized under a common object. A former colleague of mine found a recipe on SO using type. I tried to switch to Enums for that purpose, but occasionally it did not work well with os.path APIs - so I switched (back) to namedtuples

import time, re, collections
def make_enum(*enum_args, **enum_kwargs):
   _tokenizer = lambda s: re.sub('\W+', '_', s)
   enum_kwargs = {k.upper(): v for k, v in enum_kwargs.items()}

   enum_kwargs.update([(_tokenizer(s).upper(), s) for s in enum_args])
   return collections.namedtuple('_C_{:x}'.format(hash(time.time())), enum_kwargs.keys())(**enum_kwargs)

C = make_enum('true', 'false', sentence='This is long')

So that gives me nice object that helps me to avoid mismatched string constants bug

In [15]: vars(C)
Out[15]:
OrderedDict([('SENTENCE', 'This is long'),
             ('FALSE', 'false'),
             ('TRUE', 'true')])

In [16]: C.SENTENCE
Out[16]: 'This is long'

In [17]: C.FALSE
Out[17]: 'false'

This is to be usually called at the module level only. What good will it be for developer to have it tucked within a function? None at all.

In general, as the rules go - out of the second part, 10 and 12 excluded, they mostly follow common sense. You may need try for Python version adjustments; 12 makes no sense - especially since you may need to have (most common case)

sys.path.append()

I think that artificial restrictions on the language stifle productivity, creativity and job satisfaction. I have quit a job, where (misquoting my C++ instructor from long ago) Python-- was the standard .

On the pro side,  they may win you Ig Nobel prize nomination   .

[Ofnuts]

On the pro side,  they may win you Ig Nobel prize nomination   .

More like a Turding Award :)