# [Tutor] namespaces and global

Dave Angel davea at ieee.org
Thu Oct 15 13:48:06 CEST 2009

```Jose Amoreira wrote:
> Alan, Kent, hello!
> Thanks for your help. As for your "curiosity", I'm teaching elementary physics
> to undergraduates in computer engineering. Trying to speak my students'
> language, I wanted to show them simple applications that compute numerical
> values for the kinematics formulas of uniformly accelerated motion (the weaker
> students call these formulas Chinese gibberish).
> What I had in mind was to have a module define vectors and vector algebra
> operations using a simple class definition, and another with kinematics
> formulas, like (for uniformly accelerated motion)
>
> def pos(t):
>     return r0+v0*t+0.5*a*t**2
>
> Here r0 (initial position) v0 (initial velocity) and a (acceleration) are
> global vector parameters which I'd define in an interactive session with the
> students, but I'd rather not include them in the formal parameter list of
> function pos, just because they aren't usually displayed as such in physical
> formulae. I'd like to keep the look and feel of those formulas in the
> interactive python session, without having to type the function definitions in
> that session, but rather import them from a pre-prepared module file.
>
> Anyway, thanks again!
> Best Regards,
> Jose
>
>
> On Wednesday 14 October 2009 06:18:28 pm Alan Gauld wrote:
>
>> "Jose Amoreira" <ljmamoreira at gmail.com> wrote
>>
>>
>>> Of course I could redefine my module function, including the parameter a
>>> in
>>> the list of arguments, but I'd rather not.
>>>
>> Why not? That would be good computer science practice and the
>> most reliable way to do it. Why do you not want to go down that
>> route? Is there a specific reason to use a global variable when
>> use of globals is normally considered bad practice?
>>
>> I'm curious?
>>
>
>

I see nothing "wrong" with using different modularity rules in
interactive sessions than you would in a formally written program.  So
I'm going to show you the direct approach first, then a "preferable" one.

module assumes are going to be set.

Then in the interactive session, instead of using
from defs import f

Use
import defs
Followed by either
f = defs.f           or        from defs import f

Now, when defining the global, you have to put it in the right place,
which is in the defs module.  Simply use
defs.a = 3

and your function will work as you expect.

The "preferable" method might be to make these functions methods of a
class.  It's perfectly reasonable to have method attributes for all
these values you're calling globals.  And it's perfectly reasonble for a
class method to access those attributes as needed, in addition to its
own arguments.

In terms of typing in the interpreter, it comes out pretty similar.
Instead of defs.a,   you use  obj.a.  Only catch is that you call the
function as  obj.f().  And even that could be finessed if you wanted.

If you had lots of functions, and the "globals" varied among them, I'd
probably do the class approach.  But if they're all similar enough that
a single set of globals makes sense for all of them, then you've got