-1

In Matlab I can write a program that calls a sub-function which is saved to an external file. In that sub-function I can use variables without declaring them locally as long as they have been defined globally before. Is that kind of behaviour possible in python too?

An example would be a sub-function that should plot something. Currently I'm passing numpy (np) and matplotlib (plt) as an argument to that function

def plot_weights(weights,session,np,plt):
    ...

The example above comes from a tensorflow tutorial, so session stands for a tensorflow session.

Is it possible to define a function like this 

def plot_weights(weights):
    ...

and make python take session, np, plt as some global variables?

mcExchange
  • 6,154
  • 12
  • 57
  • 103
  • Are you searching for something like [`global`](http://stackoverflow.com/questions/423379/using-global-variables-in-a-function-other-than-the-one-that-created-them)? –  Jan 16 '17 at 09:50
  • You are advocating *namespace pollution*. The problems come when you try to scale this by adding more modules and you get name collisions (more than one module using the same name). You have to keep track of all the names being used in every module, and the module author cannot alter anything. You have to be careful not to use those names in you own code as well. Support becomes a nightmare because you can't tell who altered what and when. It also kills kittens. – cdarke Jan 16 '17 at 10:08
  • According to the answers given below, `global` does not mean global across modules so it seems that I cannot really get around passing all objects as function arguments. In case of numpy and matplotlib I assume I could at least import them in the sub-function itself instead of passing them as argument? It sounds like this reloading of modules would be slow however... – mcExchange Jan 16 '17 at 10:14

2 Answers2

3

I think it's better not to walk this path in Python. You could define session in another module (call it m) and then you must always refer to it as m.session, and not from m import session.

I believe using functions to retrieve global state is the better way, but avoiding globals altogether is the best.

Israel Unterman
  • 13,158
  • 4
  • 28
  • 35
2

The first point is that in Python, a "global" name is only global to the module - there's no "real", process-level global namespace. So no, you cannot have a scenario where module A sets a couple globals, import a function from module B, and module B automagically sees module A's globals (well... not without resorting to very dirty tricks at least).

The second point is that it's actually a GoodThing(tm). Depending on global state makes the code muchy harder to understand and quickly leads to rather unpredictable behaviour. This is already true when this global state is defined in the same module as the code depending on it, and when you star having modules depending on other modules properly defining process-global names all bets are off.

Also having the ability to "inject" a function's dependencies not only makes for better readibility and predictability but also makes unit testing much easier.

bruno desthuilliers
  • 75,974
  • 6
  • 88
  • 118