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

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

Running external module and accessing the created objects

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

Contents

  Running external module and accessing the created objects  Kene Meniru <Kene.Meniru@illom.org> - 2013-03-08 22:06 -0500
    Re: Running external module and accessing the created objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-09 08:03 +0000
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-09 06:05 -0500
        Re: Running external module and accessing the created objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-09 11:34 +0000
      Re: Running external module and accessing the created objects Chris Angelico <rosuav@gmail.com> - 2013-03-09 22:47 +1100
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-09 07:02 -0500
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-09 10:34 -0500
        Re: Running external module and accessing the created objects Rick Johnson <rantingrickjohnson@gmail.com> - 2013-03-09 08:51 -0800
          Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-09 12:21 -0500
            Re: Running external module and accessing the created objects Rick Johnson <rantingrickjohnson@gmail.com> - 2013-03-09 10:33 -0800
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-09 11:12 -0500
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-09 11:56 -0500
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-09 12:20 -0500
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-09 12:39 -0500
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-09 13:18 -0500
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-11 19:57 -0400
        Re: Running external module and accessing the created objects Rick Johnson <rantingrickjohnson@gmail.com> - 2013-03-11 23:40 -0700
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-11 20:48 -0400
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-11 21:23 -0400
      Re: Running external module and accessing the created objects Kene Meniru <Kene.Meniru@illom.org> - 2013-03-11 21:58 -0400
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-11 22:16 -0400
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-11 22:11 -0400
      Re: Running external module and accessing the created objects Michael Torrie <torriem@gmail.com> - 2013-03-11 22:05 -0600
      Re: Running external module and accessing the created objects Dave Angel <davea@davea.name> - 2013-03-12 07:20 -0400
      Re: Running external module and accessing the created objects Kene Meniru <kemeniru@gmail.com> - 2013-03-12 13:38 +0000
      Re: Running external module and accessing the created objects Kene Meniru <kemeniru@gmail.com> - 2013-03-12 13:28 +0000

Page 2 of 2 — ← Prev page 1 [2]

#41105

On 03/11/2013 09:58 PM, Kene Meniru wrote:
> Dave Angel wrote:
>
>> On 03/11/2013 07:57 PM, Kene Meniru wrote:
>
>>
>> I hope you're just kidding.  execfile() and exec() are two of the most
>> dangerous mechanisms around.  import or __import__() would be much
>> better, as long as your user hasn't already run myapp.py as his script.
>>
>
> Tried __import__ and it seems to execute the myapp.py just like execfile
> however it only provides access to objects defined in the module myapp.py
> only. Like I mentioned, my program has multiple packages and the objects
> myappwin needs access to are stored in an object in another module called
> doc.py.
>
> - myapp.py provides the functions used to describe 3D objects
> - app.py is imported into myapp.py and is called by the functions after they
> create the 3D objects.
> - app.py uses another module called doc.py which app.py imports to save the
> objects in a class with a dictionary.
> - myappwin needs to access the dictionary in the class inside the doc
> module.
>

If you need access to modules in your own framework, then import them 
yourself.  You don't need any strange indirection through the myapp.py 
module.  It's because you said that name was arbitrary and would change 
from run to run that we had to special case it.

Same as you do with sys module in the standard library.  It may get 
imported from dozens of places, and as long as they all import it by simple
     import sys

there's no special problem accessing its globals.


-- 
DaveA

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

#41106

On 03/11/2013 09:23 PM, Kene Meniru wrote:
> Dave Angel wrote:
>
>> On 03/11/2013 07:57 PM, Kene Meniru wrote:
>
>>
>> I hope you're just kidding.  execfile() and exec() are two of the most
>> dangerous mechanisms around.  import or __import__() would be much
>> better, as long as your user hasn't already run myapp.py as his script.
>>
>
> It does what I want. Security is another issue and I understand but can't
> help it until I find another solution.
>
> import does not do what I want.
>
> How does __import__() work and what do you mean "as long as your user hasn't
> already run myapp.py as his script."?
>

The __import__() function is defined
    http://docs.python.org/2/library/functions.html#__import__


appname = "myapp"
usermodule = __import__(appname, globals(), locals(), [], -1)

And now you can use usermodule as though you had imported it in the 
usual way.

As for my other caveat, I've said it before in this thread.  Make sure 
you don't ever load a module by more than one name, or you'll end up 
with a mess.  And that includes the original script, which is loaded by 
the name '__main__'

You also should avoid any circular import, as it can be very tricky to 
deal with them.

As I said earlier in the thread:

 >>>>
 >>>> For example the __import__() function can import a module that you
 >>>> don't know the name of ahead of time.  It's not often the right
 >>>> answer, though, so I hesitate to suggest it.
 >>>>
 >>>> For another example, if you import a module by two different names,
 >>>> or if you import the "module" that is your starting script, then
 >>>> you can end up with two instances of such a module, with all sorts
 >>>> of negative implications about global data or class attributes
 >>>> stored in that module, or even more subtle problems.
 >>>>
 >>>> For a final example, having a circular import tree can cause
 >>>> problems if any of those imports have any global code (like class
 >>>> initialization, defining constants, etc.).  It's generally much
 >>>> better to define a strict hierarchy of who imports whom.



-- 
DaveA

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

#41107

On 03/11/2013 06:48 PM, Dave Angel wrote:
> I hope you're just kidding.  execfile() and exec() are two of the most 
> dangerous mechanisms around.  import or __import__() would be much 
> better, as long as your user hasn't already run myapp.py as his script.

It's not possible to setuid a python script, so I don't see how execfile
or exec is any more dangerous than the user creating a shell script that
rm -rf * things, and then running it.

Bash "exec's" scripts all the time that users create and provide.  How
is this different and what issues did you have in mind, exactly?

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

#41114

On 03/12/2013 12:05 AM, Michael Torrie wrote:
> On 03/11/2013 06:48 PM, Dave Angel wrote:
>> I hope you're just kidding.  execfile() and exec() are two of the most
>> dangerous mechanisms around.  import or __import__() would be much
>> better, as long as your user hasn't already run myapp.py as his script.
>
> It's not possible to setuid a python script, so I don't see how execfile
> or exec is any more dangerous than the user creating a shell script that
> rm -rf * things, and then running it.
>
> Bash "exec's" scripts all the time that users create and provide.  How
> is this different and what issues did you have in mind, exactly?
>

Mainly that exec and execfile are a slippery slope for a new programmer. 
  Once as they get it in their minds that this is the way to do things, 
they'll soon fall into using one of them on raw_input() data, on network 
data, and on other untrusted sources.


-- 
DaveA

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

#41121

Michael Torrie <torriem <at> gmail.com> writes:

> It's not possible to setuid a python script, so I don't see how execfile
> or exec is any more dangerous than the user creating a shell script that
> rm -rf * things, and then running it.
> 
> Bash "exec's" scripts all the time that users create and provide.  How
> is this different and what issues did you have in mind, exactly?
> 

This is close to my reasoning too, although I appreciate Dave's concern.

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

#41122

Dave Angel <davea <at> davea.name> writes:

> 
> The __import__() function is defined
>     http://docs.python.org/2/library/functions.html#__import__
> 

Thanks. The name of the imported file will change with each user and for
each project so according to the this reference using this in my situation makes
sense.

> appname = "myapp"
> usermodule = __import__(appname, globals(), locals(), [], -1)
> 
> And now you can use usermodule as though you had imported it in the 
> usual way.
> 

Thanks. This worked! I was using __import__ without the other arguments
before. I guess did not think it will work :-)

> As for my other caveat, I've said it before in this thread.  Make sure 
> you don't ever load a module by more than one name, or you'll end up 
> with a mess.  And that includes the original script, which is loaded by 
> the name '__main__'
> 
> You also should avoid any circular import, as it can be very tricky to 
> deal with them.
> 

The two programs are separate, there is no fear of a circular import. Also,
I need only a function to get access to the objects in the other module so
the import is inside the function... no fear of ending up in a mess.

Thanks. I guess this makes more sense than execfile and it works.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web