Re: [Jython-users] Redirecting stdout from PythonInterpreter

[Santosh Tiwari <tiwaris@gm...>]

Digging deeper into the code, it appears to me that if I am using the
PythonInterpreter in separate threads, I should have a new system state for
each instance that is in a separate thread.



On Wed, Mar 10, 2010 at 9:28 AM, Santosh Tiwari <tiwaris@...> wrote:

> So, it is generally a good idea to *always* create a new PySystemState and
> pass it to the constructor when creating a new instance of PythonInterpreter
> if we want the two instances to be completely independent. Am I right?
>
> Can somebody approve or disapprove of my statement?
>
>
> On Wed, Mar 10, 2010 at 9:27 AM, Santosh Tiwari <tiwaris@...> wrote:
>
>> So, it is generally a good idea to *always* create a new PySystemState
>> and pass it to the constructor when creating a new instance of
>> PythonInterpreter if we want the two instances to be completely independent.
>>
>>
>>
>>
>> On Wed, Mar 10, 2010 at 6:05 AM, <john.m.baker@...> wrote:
>>
>>> Right.  I had previously created a PythonInterpreter and need to create
>>> a new one with a separate state for each stdout stream:
>>>
>>>         PythonInterpreter.initialize(System.getProperties(), null, new
>>> String[0]);
>>>         PySystemState systemState = new PySystemState();
>>>         pi = new PythonInterpreter(null, systemState);
>>>         pi.setOut(outputStream);
>>>         pi.setErr(outputStream);
>>>
>>> I think PythonInterpreter could be improved by making that more obvious,
>>> or by creating two versions of it - one which uses a 'shared state' and
>>> another which creates a new PySystemState each time it's constructed.
>>>
>>>
>>
>
>
> --
> Santosh Tiwari
> tiwaris@...
>



-- 
Santosh Tiwari
tiwaris@...

Re: [Jython-users] Redirecting stdout from PythonInterpreter

[<john.m.baker@no...>]

I think it's too easy for anyone new to the framework to believe an
instance of PythonInterpreter is a new fresh not-connected to anything
previous instance.  It would make more sense to make PythonInterpreter
totally independent, and create another class that makes use of this
'shared' state, and have that very well documented (what's shared,
threadsafeness, etc.)

 

From: Santosh Tiwari [mailto:tiwaris@...] 
Sent: 10 March 2010 14:27
To: Baker, John (IT/UK); jython-users@...
Subject: Re: [Jython-users] Redirecting stdout from PythonInterpreter

 

So, it is generally a good idea to always create a new PySystemState and
pass it to the constructor when creating a new instance of
PythonInterpreter if we want the two instances to be completely
independent.




On Wed, Mar 10, 2010 at 6:05 AM, <john.m.baker@...> wrote:

Right.  I had previously created a PythonInterpreter and need to create
a new one with a separate state for each stdout stream:

        PythonInterpreter.initialize(System.getProperties(), null, new
String[0]);
        PySystemState systemState = new PySystemState();
        pi = new PythonInterpreter(null, systemState);
        pi.setOut(outputStream);
        pi.setErr(outputStream);

I think PythonInterpreter could be improved by making that more obvious,
or by creating two versions of it - one which uses a 'shared state' and
another which creates a new PySystemState each time it's constructed.

 

 




This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm

Re: [Jython-users] Redirecting stdout from PythonInterpreter

[Santosh Tiwari <tiwaris@gm...>]

So, it is generally a good idea to *always* create a new PySystemState and
pass it to the constructor when creating a new instance of PythonInterpreter
if we want the two instances to be completely independent. Am I right?

Can somebody approve or disapprove of my statement?

On Wed, Mar 10, 2010 at 9:27 AM, Santosh Tiwari <tiwaris@...> wrote:

> So, it is generally a good idea to *always* create a new PySystemState and
> pass it to the constructor when creating a new instance of PythonInterpreter
> if we want the two instances to be completely independent.
>
>
>
>
> On Wed, Mar 10, 2010 at 6:05 AM, <john.m.baker@...> wrote:
>
>> Right.  I had previously created a PythonInterpreter and need to create
>> a new one with a separate state for each stdout stream:
>>
>>         PythonInterpreter.initialize(System.getProperties(), null, new
>> String[0]);
>>         PySystemState systemState = new PySystemState();
>>         pi = new PythonInterpreter(null, systemState);
>>         pi.setOut(outputStream);
>>         pi.setErr(outputStream);
>>
>> I think PythonInterpreter could be improved by making that more obvious,
>> or by creating two versions of it - one which uses a 'shared state' and
>> another which creates a new PySystemState each time it's constructed.
>>
>>
>


-- 
Santosh Tiwari
tiwaris@...

Re: [Jython-users] Redirecting stdout from PythonInterpreter

[Santosh Tiwari <tiwaris@gm...>]

So, it is generally a good idea to *always* create a new PySystemState and
pass it to the constructor when creating a new instance of PythonInterpreter
if we want the two instances to be completely independent.



On Wed, Mar 10, 2010 at 6:05 AM, <john.m.baker@...> wrote:

> Right.  I had previously created a PythonInterpreter and need to create
> a new one with a separate state for each stdout stream:
>
>         PythonInterpreter.initialize(System.getProperties(), null, new
> String[0]);
>         PySystemState systemState = new PySystemState();
>         pi = new PythonInterpreter(null, systemState);
>         pi.setOut(outputStream);
>         pi.setErr(outputStream);
>
> I think PythonInterpreter could be improved by making that more obvious,
> or by creating two versions of it - one which uses a 'shared state' and
> another which creates a new PySystemState each time it's constructed.
>
>

Re: [Jython-users] Redirecting stdout from PythonInterpreter

[<john.m.baker@no...>]

Right.  I had previously created a PythonInterpreter and need to create
a new one with a separate state for each stdout stream:

         PythonInterpreter.initialize(System.getProperties(), null, new
String[0]); 
         PySystemState systemState = new PySystemState(); 
         pi = new PythonInterpreter(null, systemState); 
         pi.setOut(outputStream);
         pi.setErr(outputStream);        

I think PythonInterpreter could be improved by making that more obvious,
or by creating two versions of it - one which uses a 'shared state' and
another which creates a new PySystemState each time it's constructed.

> -----Original Message-----
> From: Baker, John (IT/UK)
> Sent: 10 March 2010 10:11
> To: Baker, John (IT/UK); jython-dev@...; jython-
> users@...
> Subject: RE: [Jython-users] Redirecting stdout from PythonInterpreter
> 
> Interestingly, the debugger shows me that the PySystemState has a
> variable stdout which points at the FileOutputStream, and __stdout__
> which points to a PyFile, writing to a TextIOWrapper.
> 
> > -----Original Message-----
> > From: Baker, John (IT/UK)
> > Sent: 10 March 2010 09:38
> > To: jython-dev@...; jython-users@...
> > Subject: Re: [Jython-users] Redirecting stdout from
PythonInterpreter
> >
> > I need to create a servlet, unfortunately.  However, this is all a
> bit
> > weird.  If I run a standalone application, I can send the output to
a
> > file, but if I do this:
> >
> >          File x = File.createTempFile("jfarm", null);
> >          log.info("Writing to temp file "+x.getPath());
> >          fos = new FileOutputStream(x);
> >          pi.setOut(fos);
> >          pi.setErr(fos);
> >
> > In the servlet, the file is created but remains empty and the output
> > goes to stdout!
> >
> > The PythonInterpreter is created prior to that and is a new
instance,
> > although a few will have been created so if there are any statics
> > inside
> > PythonInterpreter then perhaps the fault lies elsewhere..
> >
> > > -----Original Message-----
> > > From: Alan Kennedy [mailto:jython-dev@...]
> > > Sent: 09 March 2010 17:28
> > > To: jython-users@...
> > > Subject: Re: [Jython-users] Redirecting stdout from
> PythonInterpreter
> > >
> > > [Alan]
> > > >> You haven't shown us the definition of outputStream. Is it a
> > > >> FileOutputStream? Some other form of OuputStream?
> > >
> > > [John]
> > > > It's request.getOutputStream() - I am assuming that if I set
that
> > on
> > > pi,
> > > > it will write to the output stream of a servlet request.
> > > > Perhaps it's a poor assumption ? :-)
> > >
> > > I presume you mean response.getOutputStream()?
> > >
> > > http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-
> > > mr2/javax/servlet/ServletResponse.html#getOutputStream%28%29
> > >
> > > response.getOutputStream() should return a ServletOutputStream,
> which
> > > is a subclass of java.io.OutputStream, so it should be acceptable
> as
> > a
> > > parameter to setOut(). So I'm not sure why it wouldn't be working.
> > >
> > > Things to note include
> > >
> > > 1. The setOut method is actually a method of PySystemState, which
> is
> > > by default shared by all interpreters that are created without an
> > > explicit PySystemState parameter. See the source of modjy for how
> to
> > > do the PySystemState/PythonInterpreter dance, on lines 105 to 108.
> > >
> > >
> >
>
http://fisheye3.atlassian.com/browse/jython/trunk/jython/src/com/xhaus/
> > > modjy/ModjyJServlet.java?r=6866
> > >
> > > Although if you're only creating a single interpreter, that
> shouldn't
> > > make any difference.
> > >
> > > 2. I would not consider it good practice to handle output this
way:
> > > what happens if you get an exception part way through generating
> your
> > > output?
> > >
> > > Instead, I would recommend that you use either of the two python
> > > Servlet mechanisms provided with jython, i.e.
> > >
> > > A: Modjy, the Servlets->WSGI gateway. The documentation refers to
> > > Tomcat throughout.
> > >
> > > http://modjy.xhaus.com
> > >
> > > Using WSGI with modjy makes writing applications as simple as
> follows
> > > (using the standard demo configuration)
> > >
> > > def handler(environ, start_response_callable):
> > >   start_response_callable("200 OK", [('content-type',
> 'text/html')])
> > >   return ["<html><h1>Hello World!</h1></html>"]
> > >
> > > See the "modjy_webapp" directory in the Demo directory of a jython
> > > installation.
> > >
> > > B: org.python.util.PyServlet
> > >
> > >
> >
>
http://fisheye3.atlassian.com/browse/jython/trunk/jython/src/org/python
> > > /util/PyServlet.java
> > >
> > > Both of these mechanisms have already defined the handling of
> output
> > > and errors, and are known to work.
> > >
> > > Regards,
> > >
> > > Alan.
> >
> >
> >
> >
> > This e-mail (including any attachments) is confidential, may contain
> > proprietary or privileged information and is intended for the named
> > recipient(s) only. Unintended recipients are prohibited from taking
> > action
> > on the basis of information in this e-mail and must delete all
copies.
> > Nomura will not accept responsibility or liability for the accuracy
> or
> > completeness of, or the presence of any virus or disabling code in,
> > this
> > e-mail. If verification is sought please request a hard copy. Any
> > reference
> > to the terms of executed transactions should be treated as
> preliminary
> > only
> > and subject to formal written confirmation by Nomura. Nomura
reserves
> > the
> > right to monitor e-mail communications through its networks (in
> > accordance
> > with applicable laws). No confidentiality or privilege is waived or
> > lost by
> > Nomura by any mistransmission of this e-mail. Any reference to
> "Nomura"
> > is
> > a reference to any entity in the Nomura Holdings, Inc. group. Please
> > read
> > our Electronic Communications Legal Notice which forms part of this
> e-
> > mail:
> > http://www.Nomura.com/email_disclaimer.htm
> >
> >
> >
---------------------------------------------------------------------
> --
> > -------
> > Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Jython-users mailing list
> > Jython-users@...
> > https://lists.sourceforge.net/lists/listinfo/jython-users



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm

Re: [Jython-users] Redirecting stdout from PythonInterpreter

[<john.m.baker@no...>]

Interestingly, the debugger shows me that the PySystemState has a
variable stdout which points at the FileOutputStream, and __stdout__
which points to a PyFile, writing to a TextIOWrapper.

> -----Original Message-----
> From: Baker, John (IT/UK)
> Sent: 10 March 2010 09:38
> To: jython-dev@...; jython-users@...
> Subject: Re: [Jython-users] Redirecting stdout from PythonInterpreter
> 
> I need to create a servlet, unfortunately.  However, this is all a bit
> weird.  If I run a standalone application, I can send the output to a
> file, but if I do this:
> 
>          File x = File.createTempFile("jfarm", null);
>          log.info("Writing to temp file "+x.getPath());
>          fos = new FileOutputStream(x);
>          pi.setOut(fos);
>          pi.setErr(fos);
> 
> In the servlet, the file is created but remains empty and the output
> goes to stdout!
> 
> The PythonInterpreter is created prior to that and is a new instance,
> although a few will have been created so if there are any statics
> inside
> PythonInterpreter then perhaps the fault lies elsewhere..
> 
> > -----Original Message-----
> > From: Alan Kennedy [mailto:jython-dev@...]
> > Sent: 09 March 2010 17:28
> > To: jython-users@...
> > Subject: Re: [Jython-users] Redirecting stdout from
PythonInterpreter
> >
> > [Alan]
> > >> You haven't shown us the definition of outputStream. Is it a
> > >> FileOutputStream? Some other form of OuputStream?
> >
> > [John]
> > > It's request.getOutputStream() - I am assuming that if I set that
> on
> > pi,
> > > it will write to the output stream of a servlet request.
> > > Perhaps it's a poor assumption ? :-)
> >
> > I presume you mean response.getOutputStream()?
> >
> > http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-
> > mr2/javax/servlet/ServletResponse.html#getOutputStream%28%29
> >
> > response.getOutputStream() should return a ServletOutputStream,
which
> > is a subclass of java.io.OutputStream, so it should be acceptable as
> a
> > parameter to setOut(). So I'm not sure why it wouldn't be working.
> >
> > Things to note include
> >
> > 1. The setOut method is actually a method of PySystemState, which is
> > by default shared by all interpreters that are created without an
> > explicit PySystemState parameter. See the source of modjy for how to
> > do the PySystemState/PythonInterpreter dance, on lines 105 to 108.
> >
> >
>
http://fisheye3.atlassian.com/browse/jython/trunk/jython/src/com/xhaus/
> > modjy/ModjyJServlet.java?r=6866
> >
> > Although if you're only creating a single interpreter, that
shouldn't
> > make any difference.
> >
> > 2. I would not consider it good practice to handle output this way:
> > what happens if you get an exception part way through generating
your
> > output?
> >
> > Instead, I would recommend that you use either of the two python
> > Servlet mechanisms provided with jython, i.e.
> >
> > A: Modjy, the Servlets->WSGI gateway. The documentation refers to
> > Tomcat throughout.
> >
> > http://modjy.xhaus.com
> >
> > Using WSGI with modjy makes writing applications as simple as
follows
> > (using the standard demo configuration)
> >
> > def handler(environ, start_response_callable):
> >   start_response_callable("200 OK", [('content-type', 'text/html')])
> >   return ["<html><h1>Hello World!</h1></html>"]
> >
> > See the "modjy_webapp" directory in the Demo directory of a jython
> > installation.
> >
> > B: org.python.util.PyServlet
> >
> >
>
http://fisheye3.atlassian.com/browse/jython/trunk/jython/src/org/python
> > /util/PyServlet.java
> >
> > Both of these mechanisms have already defined the handling of output
> > and errors, and are known to work.
> >
> > Regards,
> >
> > Alan.
> 
> 
> 
> 
> This e-mail (including any attachments) is confidential, may contain
> proprietary or privileged information and is intended for the named
> recipient(s) only. Unintended recipients are prohibited from taking
> action
> on the basis of information in this e-mail and must delete all copies.
> Nomura will not accept responsibility or liability for the accuracy or
> completeness of, or the presence of any virus or disabling code in,
> this
> e-mail. If verification is sought please request a hard copy. Any
> reference
> to the terms of executed transactions should be treated as preliminary
> only
> and subject to formal written confirmation by Nomura. Nomura reserves
> the
> right to monitor e-mail communications through its networks (in
> accordance
> with applicable laws). No confidentiality or privilege is waived or
> lost by
> Nomura by any mistransmission of this e-mail. Any reference to
"Nomura"
> is
> a reference to any entity in the Nomura Holdings, Inc. group. Please
> read
> our Electronic Communications Legal Notice which forms part of this e-
> mail:
> http://www.Nomura.com/email_disclaimer.htm
> 
> 
>
-----------------------------------------------------------------------
> -------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Jython-users mailing list
> Jython-users@...
> https://lists.sourceforge.net/lists/listinfo/jython-users



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm

Re: [Jython-users] Redirecting stdout from PythonInterpreter

[<john.m.baker@no...>]

I need to create a servlet, unfortunately.  However, this is all a bit
weird.  If I run a standalone application, I can send the output to a
file, but if I do this:

         File x = File.createTempFile("jfarm", null);
         log.info("Writing to temp file "+x.getPath());
         fos = new FileOutputStream(x);
         pi.setOut(fos);
         pi.setErr(fos);

In the servlet, the file is created but remains empty and the output
goes to stdout!

The PythonInterpreter is created prior to that and is a new instance,
although a few will have been created so if there are any statics inside
PythonInterpreter then perhaps the fault lies elsewhere..

> -----Original Message-----
> From: Alan Kennedy [mailto:jython-dev@...]
> Sent: 09 March 2010 17:28
> To: jython-users@...
> Subject: Re: [Jython-users] Redirecting stdout from PythonInterpreter
> 
> [Alan]
> >> You haven't shown us the definition of outputStream. Is it a
> >> FileOutputStream? Some other form of OuputStream?
> 
> [John]
> > It's request.getOutputStream() - I am assuming that if I set that on
> pi,
> > it will write to the output stream of a servlet request.
> > Perhaps it's a poor assumption ? :-)
> 
> I presume you mean response.getOutputStream()?
> 
> http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-
> mr2/javax/servlet/ServletResponse.html#getOutputStream%28%29
> 
> response.getOutputStream() should return a ServletOutputStream, which
> is a subclass of java.io.OutputStream, so it should be acceptable as a
> parameter to setOut(). So I'm not sure why it wouldn't be working.
> 
> Things to note include
> 
> 1. The setOut method is actually a method of PySystemState, which is
> by default shared by all interpreters that are created without an
> explicit PySystemState parameter. See the source of modjy for how to
> do the PySystemState/PythonInterpreter dance, on lines 105 to 108.
> 
>
http://fisheye3.atlassian.com/browse/jython/trunk/jython/src/com/xhaus/
> modjy/ModjyJServlet.java?r=6866
> 
> Although if you're only creating a single interpreter, that shouldn't
> make any difference.
> 
> 2. I would not consider it good practice to handle output this way:
> what happens if you get an exception part way through generating your
> output?
> 
> Instead, I would recommend that you use either of the two python
> Servlet mechanisms provided with jython, i.e.
> 
> A: Modjy, the Servlets->WSGI gateway. The documentation refers to
> Tomcat throughout.
> 
> http://modjy.xhaus.com
> 
> Using WSGI with modjy makes writing applications as simple as follows
> (using the standard demo configuration)
> 
> def handler(environ, start_response_callable):
>   start_response_callable("200 OK", [('content-type', 'text/html')])
>   return ["<html><h1>Hello World!</h1></html>"]
> 
> See the "modjy_webapp" directory in the Demo directory of a jython
> installation.
> 
> B: org.python.util.PyServlet
> 
>
http://fisheye3.atlassian.com/browse/jython/trunk/jython/src/org/python
> /util/PyServlet.java
> 
> Both of these mechanisms have already defined the handling of output
> and errors, and are known to work.
> 
> Regards,
> 
> Alan.




This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm