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.

1 2	#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".

1 2 3 4

#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?

1 2 3 4 5 6 7 8

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

1 2 3

#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:

1 2 3 4 5

# "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

1 2 3 4 5 6 7 8 9

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

1 2 3 4 5 6 7 8 9 10 11

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)

1	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 :)