Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #8296 > unrolled thread

Project-wide variable...

Back to article view | Back to comp.lang.python

Contents

  Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 06:41 -0700
    Re: Project-wide variable... Calvin Spealman <ironfroggy@gmail.com> - 2011-06-23 09:51 -0400
    Re: Project-wide variable... Noah Hall <enalicho@gmail.com> - 2011-06-23 14:59 +0100
      Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 07:09 -0700
        Re: Project-wide variable... Peter Otten <__peter__@web.de> - 2011-06-23 16:42 +0200
          Re: Project-wide variable... "bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> - 2011-06-23 08:20 -0700
          Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 10:48 -0700
        Re: Project-wide variable... Noah Hall <enalicho@gmail.com> - 2011-06-23 15:55 +0100
        Re: Project-wide variable... Terry Reedy <tjreedy@udel.edu> - 2011-06-23 14:10 -0400
          Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 19:01 -0700
            Re: Project-wide variable... Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-06-24 02:11 +0000
              Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 20:49 -0700
                Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 21:01 -0700
                  Re: Project-wide variable... alex23 <wuwei23@gmail.com> - 2011-06-23 21:04 -0700
                Re: Project-wide variable... Terry Reedy <tjreedy@udel.edu> - 2011-06-24 02:27 -0400
                  Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-24 04:30 -0700
                    Re: Project-wide variable... Terry Reedy <tjreedy@udel.edu> - 2011-06-24 17:19 -0400
    Re: Project-wide variable... Guillaume Martel-Genest <guillaumemg@gmail.com> - 2011-06-23 10:18 -0700
      Re: Project-wide variable... Noah Hall <enalicho@gmail.com> - 2011-06-23 18:42 +0100
        Re: Project-wide variable... Gnarlodious <gnarlodious@gmail.com> - 2011-06-23 11:01 -0700

#8296 — Project-wide variable...

Is there a way to declare a project-wide variable and use that in all
downstream modules?

-- Gnarlir

[toc] | [next] | [standalone]

#8297

No, but you can define a name in one module and import that into others.

On Thu, Jun 23, 2011 at 9:41 AM, Gnarlodious <gnarlodious@gmail.com> wrote:
> Is there a way to declare a project-wide variable and use that in all
> downstream modules?
>
> -- Gnarlir
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

[toc] | [prev] | [next] | [standalone]

#8298

On Thu, Jun 23, 2011 at 2:41 PM, Gnarlodious <gnarlodious@gmail.com> wrote:
> Is there a way to declare a project-wide variable and use that in all
> downstream modules?

Well, the standard way you should do it is to use import to import a
certain variable - for example -

a.py -

x = 3


>>>from a import x
>>>x
3

[toc] | [prev] | [next] | [standalone]

#8300

On Jun 23, 7:59 am, Noah Hall wrote:
> >>>from a import x

I'm doing that:
import Module.Data as Data

However I end up doing it in every submodule, so it seems a little
redundant. I wish I could load the variable in the parent program and
have it be available in all submodules. Am I missing something?

-- Gnarlie

[toc] | [prev] | [next] | [standalone]

#8301

Gnarlodious wrote:

> On Jun 23, 7:59 am, Noah Hall wrote:
>> >>>from a import x
> 
> I'm doing that:
> import Module.Data as Data

from Module import Data

There, you saved three more characters .

> However I end up doing it in every submodule, so it seems a little
> redundant. I wish I could load the variable in the parent program and
> have it be available in all submodules. Am I missing something?

You can modify the builtin namespace:

$ cat module.py
print data
$ cat main.py
import __builtin__
__builtin__.data = 42

import module
$ python main.py
42
$

But I don't think it's a good idea. Remember that "explicit is better than 
implicit".

[toc] | [prev] | [next] | [standalone]

#8307

On Jun 23, 4:42 pm, Peter Otten <__pete...@web.de> wrote:
(snip)
> > However I end up doing it in every submodule, so it seems a little
> > redundant. I wish I could load the variable in the parent program and
> > have it be available in all submodules. Am I missing something?
>
> You can modify the builtin namespace:
> But I don't think it's a good idea.

Even posting about it is already a bad idea IMHO. There are good
reasons this isn't documented.

@OP: yes, explicit imports are boring... until you have to debug and
maintain the code, and then you start to LOVE them.

[toc] | [prev] | [next] | [standalone]

#8318

On Jun 23, 8:42 am, Peter Otten wrote:

> from Module import Data
>
> There, you saved three more characters .
OK I get it, LOL.

> But I don't think it's a good idea. Remember that "explicit is better than
> implicit".
Thanks, now I know what that means.

-- Gnarlie

[toc] | [prev] | [next] | [standalone]

#8303

On Thu, Jun 23, 2011 at 3:09 PM, Gnarlodious <gnarlodious@gmail.com> wrote:
> On Jun 23, 7:59 am, Noah Hall wrote:
>> >>>from a import x
>
> I'm doing that:
> import Module.Data as Data

Well, that's not quite the same. You're using Module.Data as Data - I
guess you've done this because you've realised that import Module
means you still have to write Module.Data every time. But the correct
way to is state exactly which function or object you want - for
example, from Module import Data. Simple, right? I mean, you almost
had it, but it seems like you've gotten a little confused with various
theories.


>
> However I end up doing it in every submodule, so it seems a little
> redundant. I wish I could load the variable in the parent program and
> have it be available in all submodules. Am I missing something?

Well, generally, if you've got a variable that you need in all your
sub-modules, the chances are that your code infrastructure needs a bit
of reordering (at least, that's what I find in my case). Without
seeing your code, though, I would find it hard to make a judgement on
what you need. Perhaps reading up on the documentation will help -
http://docs.python.org/tutorial/modules.html#packages

Noah.

[toc] | [prev] | [next] | [standalone]

#8321

On 6/23/2011 10:09 AM, Gnarlodious wrote:
> On Jun 23, 7:59 am, Noah Hall wrote:
>>>> >from a import x
>
> I'm doing that:
> import Module.Data as Data
>
> However I end up doing it in every submodule, so it seems a little
> redundant. I wish I could load the variable in the parent program and
> have it be available in all submodules. Am I missing something?

Yes. Make a project ~template.py file that includes the common import.
Mine is something like

#!python3
  '''project_dir/.py -- 2011
Copyright Terry Jan Reedy

'''
from test import ftest,itest


def test_main():


if __name__ == '__main__':
     test_main()

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#8340

On Jun 23, 12:10 pm, Terry Reedy wrote:

> from test import ftest,itest
>
> def test_main():
>
> if __name__ == '__main__':
>      test_main()

I don't understand this. Can you explain, or refer me to some
documentation?

--  Gnarlie
http://Gnarlodious.com

[toc] | [prev] | [next] | [standalone]

#8342

On Thu, 23 Jun 2011 19:01:59 -0700, Gnarlodious wrote:

> On Jun 23, 12:10 pm, Terry Reedy wrote:
> 
>> from test import ftest,itest
>>
>> def test_main():
>>
>> if __name__ == '__main__':
>>      test_main()
> 
> I don't understand this. Can you explain, or refer me to some
> documentation?

What part don't you understand?

This is Terry's template. It's not meant to work as-is, he has to fill in 
the details, such as what test_main() actually does.

The "if __name__ == '__main__'" idiom is a common way of making a Python 
script. When you import a module, Python automatically adds a global to 
it called __name__, and sets it to the name of the module. E.g.:

>>> import math
>>> math.__name__
'math'

When you run a module as a script, Python sets the __name__ to '__main__' 
instead. So this is a (slightly hacky) way of distinguishing code that 
runs when the module is imported from code that runs on execution.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#8344

Let me restate my question.
Say I have a script Executable.py that calls all other scripts and
controls them:

#!/usr/local/bin/python
from Module import Data
import ModuleTest

ModuleTest.py has this:

print(Data.Plist.Structure)

Running Executable.py gives me this:
NameError: name 'Data' is not defined

1) Can I tell Executable.py to share Data with ModuleTest.py?
or if that can't be done:
2) Can I tell ModuleTest.py to "look upstream" for Data?

I have used two systems to accomplish this purpose:
1) Import Data into every module as it is loaded, which I am doing
now, and:
2) Load Data at the top and pass it downstream as a variable. This
gets a little cluttered and I quit doing it that way.

So I am looking for an easier way to load Data as an application-wide
variable. If its impossible to do what I want, I can accept that.

-- Gnarlie

[toc] | [prev] | [next] | [standalone]

#8345

Idea: It occurs to me that my application class inherits "object". Can
I set that to inherit an object that already includes data? So every
subsequent class would start off with data loaded (except for class
Data).

Seems like it should already be invented.

-- Gnarlie

[toc] | [prev] | [next] | [standalone]

#8346

On Jun 24, 2:01 pm, Gnarlodious <gnarlodi...@gmail.com> wrote:
> Seems like it should already be invented.

If you're finding you're importing the same data into every single
module, then you're doing something wrong. Creating dependencies
across modules like you're wanting is a recipe for suffering.

[toc] | [prev] | [next] | [standalone]

#8350

On 6/23/2011 11:49 PM, Gnarlodious wrote:
> Let me restate my question.
> Say I have a script Executable.py that calls all other scripts and
> controls them:
>
> #!/usr/local/bin/python
> from Module import Data
> import ModuleTest
>
> ModuleTest.py has this:
>
> print(Data.Plist.Structure)
>
> Running Executable.py gives me this:
> NameError: name 'Data' is not defined
>
> 1) Can I tell Executable.py to share Data with ModuleTest.py?

After the import is complete, yes.
import ModuleTest
ModuleTest.Data = Data

This works if the use of Data is inside a function that is not called 
during import, not if the use of Data is at toplevel or in a class 
statement outside a def.

> or if that can't be done:
> 2) Can I tell ModuleTest.py to "look upstream" for Data?

Yes if ModuleTest imports Executable, but circular imports are a bad idea.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#8372

On Jun 24, 12:27 am, Terry Reedy wrote:

> > 1) Can I tell Executable.py to share Data with ModuleTest.py?
>
> After the import is complete, yes.
> import ModuleTest
> ModuleTest.Data = Data
>
> This works if the use of Data is inside a function that is not called
> during import, not if the use of Data is at toplevel or in a class
> statement outside a def.

That works! The solution looks like this:

# controlling program:
from Module import Data
import ModuleTest
ModuleTest.Data = Data
ModuleTest.getData()

# module:
def getData():
    print(Data.Plist.Structure)


Thanks for all your help!

-- Gnarlie

[toc] | [prev] | [next] | [standalone]

#8412

On 6/24/2011 7:30 AM, Gnarlodious wrote:
> On Jun 24, 12:27 am, Terry Reedy wrote:
>
>>> 1) Can I tell Executable.py to share Data with ModuleTest.py?
>>
>> After the import is complete, yes.
>> import ModuleTest
>> ModuleTest.Data = Data
>>
>> This works if the use of Data is inside a function that is not called
>> during import, not if the use of Data is at toplevel or in a class
>> statement outside a def.
>
> That works! The solution looks like this:
>
> # controlling program:
> from Module import Data
> import ModuleTest
> ModuleTest.Data = Data
> ModuleTest.getData()
>
> # module:
> def getData():
>      print(Data.Plist.Structure)

This is a form of dependency injection, where a caller injects into a 
callee a dependency (callee) of the callee. It can be used even if the 
callee imports a dependency when it is imported. It is useful for 
testing when you want the callee to use a different dependency for 
testing. Simple example:

# MyModule
import socket
def myconnect(*args):
    ... socket.bind()

# Test_MyModule
import mock_socket
import MyModule
MyModule.socket = mock_socket
... test of MyModule, including MyModule.myconnect

Python makes this trivial without requiring that the otherwise constant 
depedency always be injected or passed (in normal production use) as a 
variable.

In your case, you are free to inject different forms of Data if you wish.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#8315

On Jun 23, 9:41 am, Gnarlodious <gnarlodi...@gmail.com> wrote:
> Is there a way to declare a project-wide variable and use that in all
> downstream modules?
>
> -- Gnarlir

What about using an environment variable?

[toc] | [prev] | [next] | [standalone]

#8317

On Thu, Jun 23, 2011 at 6:18 PM, Guillaume Martel-Genest
<guillaumemg@gmail.com> wrote:
> On Jun 23, 9:41 am, Gnarlodious <gnarlodi...@gmail.com> wrote:
>> Is there a way to declare a project-wide variable and use that in all
>> downstream modules?
>>
> What about using an environment variable?

Yes, that's fine, but only if the data is suitable for it.

[toc] | [prev] | [next] | [standalone]

#8320

On Jun 23, 11:42 am, Noah Hall wrote:

> > What about using an environment variable?
>
> Yes, that's fine, but only if the data is suitable for it.

In this case, the variable is a namespace containing the property of a
folder full of plist files. I access any dictionary item anywhere in
my webapp with a namespace like this:

Data.Plist.SectrumDB.Sectrum.Contents.Character.Type
> Unicode string

There are hundreds of these dictionary items in the namespace, and it
has been a powerful programming tool. I simply wonder if there is a
more elegant way of giving my entire application access to these
variables from the top. Apparently not, from what I gather.

-- Gnarlie
http://Gnarlodious.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web