From: Frank C. <fc...@pu...> - 2001-09-21 20:39:50
|
If anyone will confirm this is the best way to use exec and globals, I would certain appreciate your feedback. The goal is to have the Jython equivalent of server-side include files where one script calls another and can share variables. In an experiment I created two files: exec_example.py def makethecall: i=100 exec open("included.py").read() print "j=", j makethecall() included.py j=101 print "i=", i By running exec_example I see: i=100 j=101 Is this the best way to have scripts calling other scripts and returning results? -Frank -- Frank Cohen, founder, PushToTest, www.pushtotest.com, phone: 408 374 7426 Come to PushToTest for Load, a free open-source tool for performance and scalability testing and data migration. |
From: Ype K. <yk...@xs...> - 2001-09-22 13:02:40
|
Frank, >If anyone will confirm this is the best way to use exec and globals, I would >certain appreciate your feedback. > >The goal is to have the Jython equivalent of server-side include files where >one script calls another and can share variables. In an experiment I created >two files: > >exec_example.py > >def makethecall: > i=100 > exec open("included.py").read() > print "j=", j >makethecall() > > >included.py > >j=101 >print "i=", i > >By running exec_example I see: > >i=100 >j=101 > >Is this the best way to have scripts calling other scripts and returning >results? This illustrates that the global namespace passed to exec is the local namespace of the makethecall function. You can have more control over the namespaces passed to exec by passing these as arguments, too. My guess is that you are going to need this. In this particular example I think I'd prefer to use execfile(), but that is rather minor. You could also note that: - the __name__ variable in the executed code will have the value of the __name__ variable at the exec call, which might not be desirable. - the function makethecall is defined when included.py is exec'ed, There are a few other things that are normally provided by jython itself for the code it executes that you might want to consider: In case you want to control import's in exec'ed code: - sys.modules might change during the exec when the executed code imports other modules. - neither exec nor execfile does any module administration in sys.modules. You can do this yourself by (temporarily) adding a new.module() to sys.modules. In case you want more control over imports in executed code you'll need to control sys.path too, as it determines the places from which modules can be loaded. The exec'ed code might throw - a jython exception. You might want to catch it. - a java exception that you cannot catch in jython. The exec'ed code might not return. This is rather hard to control, but it is possible in jython by using a (deprecated) java call to stop the thread doing the exec. Fortunately the python language does not encourage writing endless loops. The nice thing about python/jython is that you can control almost all of these aspects when using exec or execfile. The downside is off course that you might have to write the code to do some of this. If you'd like to see an example, let me know. Regards, Ype |
From: Frank C. <fc...@pu...> - 2001-09-22 15:11:28
|
Thanks for the great reply. Lots of useful information here. I would appreciate seeing your example code too. Do I have it right that Jython can't catch Java exceptions? If so, should I implement my Java code to catch and store all exceptions and have a geterror method that returns a thrown error code to the Jython script? -Frank -- Frank Cohen, founder, PushToTest, www.pushtotest.com, phone: 408 374 7426 Come to PushToTest for Load, a free open-source tool for performance and scalability testing and data migration. > From: Ype Kingma <yk...@xs...> > Date: Sat, 22 Sep 2001 11:09:01 +0100 > To: jyt...@li... > Subject: Re: [Jython-users] exec and globals > > Frank, > >> If anyone will confirm this is the best way to use exec and globals, I would >> certain appreciate your feedback. >> >> The goal is to have the Jython equivalent of server-side include files where >> one script calls another and can share variables. In an experiment I created >> two files: >> >> exec_example.py >> >> def makethecall: >> i=100 >> exec open("included.py").read() >> print "j=", j >> makethecall() >> >> >> included.py >> >> j=101 >> print "i=", i >> >> By running exec_example I see: >> >> i=100 >> j=101 >> >> Is this the best way to have scripts calling other scripts and returning >> results? > > This illustrates that the global namespace passed to exec is the local > namespace of the makethecall function. > You can have more control over the namespaces passed to exec by passing > these as arguments, too. My guess is that you are going to need this. > In this particular example I think I'd prefer to use execfile(), but > that is rather minor. > > You could also note that: > - the __name__ variable in the executed code will have the value of the > __name__ variable at the exec call, which might not be desirable. > - the function makethecall is defined when included.py is exec'ed, > > There are a few other things that are normally provided by jython > itself for the code it executes that you might want to consider: > > In case you want to control import's in exec'ed code: > - sys.modules might change during the exec when the executed code imports > other modules. > - neither exec nor execfile does any module administration in > sys.modules. You can do this yourself by (temporarily) adding > a new.module() to sys.modules. > In case you want more control over imports in executed code you'll need to > control sys.path too, as it determines the places from which modules can > be loaded. > > The exec'ed code might throw > - a jython exception. You might want to catch it. > - a java exception that you cannot catch in jython. > > The exec'ed code might not return. This is rather hard to control, > but it is possible in jython by using a (deprecated) java call to stop > the thread doing the exec. Fortunately the python language does not > encourage writing endless loops. > > The nice thing about python/jython is that you can control almost all > of these aspects when using exec or execfile. > The downside is off course that you might have to write the code to do > some of this. If you'd like to see an example, let me know. > > Regards, > Ype > > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users |
From: Robert W. B. <rb...@di...> - 2001-09-22 22:12:37
|
On Sat, 22 Sep 2001, Frank Cohen wrote: > Thanks for the great reply. Lots of useful information here. I would > appreciate seeing your example code too. > > Do I have it right that Jython can't catch Java exceptions? Actually, Jython does catch Java exceptions. e.g.: >>> import java >>> try: ... raise java.lang.UnknownError, "Java error raised" >>> except java.lang.UnknownError: ... print "Java exception caught" ... Java exception caught >>> It catches it just the same if a Java class throws it. -robert |
From: Ype K. <yk...@xs...> - 2001-09-23 08:57:22
|
Robert, >On Sat, 22 Sep 2001, Frank Cohen wrote: >> Thanks for the great reply. Lots of useful information here. I would >> appreciate seeing your example code too. >> >> Do I have it right that Jython can't catch Java exceptions? > >Actually, Jython does catch Java exceptions. e.g.: > >>>> import java >>>> try: >... raise java.lang.UnknownError, "Java error raised" >>>> except java.lang.UnknownError: >... print "Java exception caught" >... >Java exception caught >>>> > >It catches it just the same if a Java class throws it. Could you try java.lang.OutOfMemError, too? It's already some versions of jython ago that I could not catch it in actual out of memory situations. Ype. |
From: Robert W. B. <rb...@di...> - 2001-09-23 15:36:37
|
On Sun, 23 Sep 2001, Ype Kingma wrote: > Robert, > > >On Sat, 22 Sep 2001, Frank Cohen wrote: > >> Thanks for the great reply. Lots of useful information here. I would > >> appreciate seeing your example code too. > >> > >> Do I have it right that Jython can't catch Java exceptions? > > > >Actually, Jython does catch Java exceptions. e.g.: > > > >>>> import java > >>>> try: > >... raise java.lang.UnknownError, "Java error raised" > >>>> except java.lang.UnknownError: > >... print "Java exception caught" > >... > >Java exception caught > >>>> > > > >It catches it just the same if a Java class throws it. > > Could you try java.lang.OutOfMemError, too? It's already some versions > of jython ago that I could not catch it in actual out of memory situations. > > Ype. ------------------------------------ >>> import java >>> try: ... raise java.lang.OutOfMemoryError ... except java.lang.OutOfMemoryError: ... print "Caught" ... Caught >>> ------------------------------------ The above works, but I know it's not what you are getting at. The complication of the System.exit(-1) in Py.MemoryError(OutOfMemoryError t) (file org/python/core/Py.java) is what you're referring to, isn't it? You're asking about something closer to the following: ------------------------------------- >>> import java >>> from org.python.core import Py >>> e = java.lang.OutOfMemoryError() >>> try: ... Py.MemoryError(e) ... except: ... import sys ... x = sys.exc_info() ... Out of Memory You might want to try the -mx flag to increase heap size ------------------------------------- Yes, that makes for a problem trying to catch the OutOfMemoryError. I think the difference between an error and an exception helps here. An Error is tough (likely impossible) to recover from, and javadocs even say an error "indicates serious problems that a reasonable application should not try to catch." -rb |