Dave Angel 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
s
Michael Torrie 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. H
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
On Monday, March 11, 2013 6:57:28 PM UTC-5, Kene Meniru wrote:
>
> --
> # contents of myapp.py
> import math
>
> class MyApp(object):
> def __init__(self):
> super(MyApp, self).__init__()
> self.name = "MyAppName"
>
>
> def testFunction():
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 s
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 m
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 m
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 __imp
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 wha
On 03/11/2013 07:57 PM, Kene Meniru wrote:
Here's the answer to this question.
The summary of the question: how to run a module (called myapp.py) from
another module (called myappwin.py) and be able to access the namespace of
myapp.py from myappwin.py.
--
Here's the answer to this question.
The summary of the question: how to run a module (called myapp.py) from
another module (called myappwin.py) and be able to access the namespace of
myapp.py from myappwin.py.
--
# contents of myapp.py
import math
class
On Saturday, March 9, 2013 11:21:20 AM UTC-6, Kene Meniru wrote:
> Please see my last response to Dave Angel. I think it is
> possible for a program to watch a file. I am not
> interested in menus which is why I am going this route. I
> could easily use PyQt to make this but I am not interested
>
Kene Meniru wrote:
> Dave Angel wrote:
>> If you really want two processes, then you should consider having the
>> user run the the graphic app, with a commandline parameter of user.py,
>> and have it create the user.py process. The user.py process runs till
>> it has created all the data, then
Dave Angel wrote:
>>>
>>> So the solution I am looking for is to have a graphic window open that
>>> watches user.py for changes.
>
> It would then have to be a separate executable.
This is my thinking too.
> Are you really saying
> you want this window to keep "running" after the script ends
Rick Johnson wrote:
> On Saturday, March 9, 2013 9:34:53 AM UTC-6, Kene Meniru wrote:
>
> Interactive Input
>
>
> Create an interactive environment where the user can enter
On 03/09/2013 11:56 AM, Kene Meniru wrote:
Dave Angel wrote:
On 03/09/2013 10:34 AM, Kene Meniru wrote:
To use my program the user needs a script file I will call user.py.
Functions from my program must be imported into this file with
something like "from myapp import *".
And does the user
Dave Angel wrote:
> On 03/09/2013 10:34 AM, Kene Meniru wrote:
>> To use my program the user needs a script file I will call user.py.
>> Functions from my program must be imported into this file with
>> something like "from myapp import *".
>
> And does the user run this script by doing
> p
On Saturday, March 9, 2013 9:34:53 AM UTC-6, Kene Meniru wrote:
> OK. Sorry to have caused all the confusion. Let me try
> this again.
Sounds to me like you should solve this problem in two manners:
Interactive Input
==
On 03/09/2013 10:34 AM, Kene Meniru wrote:
OK. Sorry to have caused all the confusion. Let me try this again.
Thank you very much. This is much clearer, though it's not all here.
To use my program the user needs a script file I will call user.py.
Functions from my program must be imported i
OK. Sorry to have caused all the confusion. Let me try this again.
To use my program the user needs a script file I will call user.py.
Functions from my program must be imported into this file with
something like "from myapp import *".
myapp.py is a module in my program that has all the functio
On 03/09/2013 06:05 AM, Kene Meniru wrote:
(lots of stuff that was more confusing to me than helpful)
You use the words launch, encountered, execute, and others in ways that
do not make sense to me, or are at least ambiguous.
You have an explicitly named user.py, which apparently is *not*
On Sat, Mar 9, 2013 at 10:05 PM, Kene Meniru wrote:
> I have tried importing "user.py" and/or "app.py". However there is no
> single command to call.
I haven't followed the thread in detail, but I gather you're trying to
import a file with a variable name? Instead of 'import user', try:
user = _
Steven D'Aprano wrote:
> What do you mean, "objects are saved in another object"?
>
doc.py has a dictionary. When the user describes a wall, it is passed
to the doc object to be saved in the dictionary.
>
> What happens if the user launches appwin with a different argument?
>
> If appwin c
On Fri, 08 Mar 2013 22:06:28 -0500, Kene Meniru wrote:
> Program summary:
>
> I have a module called user.py that imports another module called
> app.py. Functions in app.py are used in user.py to describe 3D objects.
> These objects are saved in another object described in doc.py.
What do you m
24 matches
Mail list logo
