Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The first and obvious question is <em>why?</em></p> <p>There are a few situations in which global variables are necessary/useful, but those are indeed few.</p> <p>Your issue is with namespaces. When you import common into second.py, <code>GLOBAL_ONE</code> comes from that namespace. When you import secondTest it still references <code>GLOBAL_ONE</code> from common.py.</p> <p>Your real issue, however, is with design. I can't think of a single logical <em>good</em> reason to implement a global variable this way. Global variables are a tricky business in Python because there's no such thing as a constant variable. However, convention is that when you want to keep something constant in Python you name it <code>WITH_ALL_CAPS</code>. Ergo:</p> <pre><code>somevar = MY_GLOBAL_VAR # good! MY_GLOBAL_VAR = somevar # What? You "can't" assign to a constant! Bad! </code></pre> <p>There are plenty of reasons that doing something like this:</p> <pre><code>earth = 6e24 def badfunction(): global earth earth += 1e5 print '%.2e' % earth </code></pre> <p>is <em>terrible.</em></p> <p>Of course if you're just doing this as an exercise in understanding namespaces and the <code>global</code> call, carry on.</p> <p>If not, some of the reasons that global variables are A Bad Thing™ are:</p> <ul> <li>Namespace pollution</li> <li>Functional integration - you want your functions to be compartmentalized</li> <li>Functional side effects - what happens when you write a function that modifies the global variable <code>balance</code> and either you or someone else is reusing your function and don't take that into account? If you were calculating account balance, all of the sudden you either have too much, or not enough. Bugs like this are difficult to find.</li> </ul> <p>If you have a function that needs a value, you should pass it that value as a parameter, unless you have a really good reason otherwise. One reason would be having a global of PI - depending on your precision needs you may want it to be <code>3.14</code>, or you may want it <code>3.14159265</code>... but that is <em>one</em> case where a global makes sense. There are probably only a handful or two of real-world cases that can use globals properly. One of the cases are constants in game programming. It's easier to import pygame.locals and use KP_UP than remember the integer value responding to that event. These are <em>exceptions</em> to the rule.</p> <p>And (at least in pygame) these constants are stored in a separate file - just for the constants. Any module that needs those constants will import said constants.</p> <p>When you program, you write functions to break your problem up into manageable chunks. Preferably a function should do <em>one</em> thing, and have no side effects. That means a function such as <em>calculatetime()</em> should calculate the time. It probably shouldn't go reading a file that contains the time, and forbid that it should do something like <em>write</em> the time somewhere. It can <em>return</em> the time, and take parameters if it needs them - both of these are good, acceptable things for functions to do. Functions are a sort of contract between you (the programmer of the function) and anyone (including you) who uses the function. Accessing <em>and changing</em> global variables are a violation of that contract because the function can modify the outside data in ways that are not defined or expected. When I use that <code>calculatetime()</code> function, I expect that it will calculate the time and probably return it, not modify the global variable time which responds to the module time that I just imported.</p> <p>Modifying global variables break the contract and the logical distinction between actions that your program takes. They can introduce bugs into your program. They make it hard to upgrade and modify functions. When you use globals as variables instead of constant, <a href="http://www.imdb.com/title/tt0071853/quotes?qt0470611" rel="nofollow noreferrer">death awaits you with sharp pointy teeth!</a></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload