Jython

[Anthony Roy]
> There is a bug in the tracker marked as "Works For Me" regarding the fact
> that PythonInterpreters all share a common system state:
> http://tinyurl.com/2vhqg8
>
> Now the reported issue is that the reporter wanted to be able to run
> different scripts in different interpreters set up in different ways. The
> issue is marked as won't fix due to the ability to pass in a new
> SystemState to the constructor of the PythonInterpreter.
>
> This is fine for single threaded applications, but once you have multiple
> threads, you have threads after the first overriding the global system
> state with it's own one, and this has the effect that earlier thread's
> global environments are replaced by the latter threads environment.

Are you certain? Why not create the second and later threads with

another_interp = new PythonInterpreter(null,new PySystemState())

as recommended by Samuele in the bug report?

Or to be more specific, what shared parts of the PySystemState class
are causing problems for your multi-threaded apps? Are you
experiencing specific problems?

> I was wondering if it was worth re-opening this issue, or whether it it
> worth raising as a feature request as pedronis suggests in the bug report.

If there are specific attributes of the PySystemState class that are
causing problems when used in a multi-threaded situation, best to
raise a separate bug report about them. Ideally the bug report should
include a java code snippet that illustrates the precise problem.

Regards,

Alan.

Hi all,

>> This is fine for single threaded applications, but once you have
>> multiple
>> threads, you have threads after the first overriding the global system
>> state with it's own one, and this has the effect that earlier thread's
>> global environments are replaced by the latter threads environment.
>
> Are you certain? Why not create the second and later threads with
> another_interp = new PythonInterpreter(null,new PySystemState())
> as recommended by Samuele in the bug report?

This makes no difference - if you look at the code in PythonInterpreter,
it's clear that doing that simply changes the static PySystemState
instance in the Py class - i.e. it replaces it globally.

> Or to be more specific, what shared parts of the PySystemState class
> are causing problems for your multi-threaded apps? Are you
> experiencing specific problems?

Actually, looking deeper there are quite a few issues that prevent Jython
being used embedded in a multi-threaded environment:

1) Global variables are kept in the system state - hence different scripts
with global variables of the same name can change the value of each
other's variables!

2) Initializing the PythonInterpreter is done through a static method -
hence you cannot supply different scripts with different sys.argv for
example.

I expect there are other issues which I haven't come across yet. I would
have thought that the point of being able to create separate
PythonInterpreters would be to provide a way of having separate sandboxes
for scripts to run in, with their own environments etc. For example, you
may have a GUI app (by nature multithreaded) and want to be able to script
different parts of it in isolated environments, so that, for example,
changing a script in the editor macro part of the program didn't interfere
with the image processing part. Otherwise the PythonInterpreter may just
as well be a singleton.

> If there are specific attributes of the PySystemState class that are
> causing problems when used in a multi-threaded situation, best to
> raise a separate bug report about them. Ideally the bug report should
> include a java code snippet that illustrates the precise problem.

I think it is the overall mechanism that needs looking at - I thought I'd
discuss it here before filing a bug. I could be missing something, but it
seems to me that an inability to work within a multi-threaded environment
is a Bad Thing, since all but the most trivial Java applications are
multi-threaded, and I would guess that one of the most common uses of
Jython is as an embedded scripting language for a Java app.

Attached is a minimal example of how the global environments of completely
different scripts interfere with each other. One Java class which sets
each script running in a different thread, and the three pythons scripts
which happen to have global variables in common. Run the java program with
a command line argument (say 'new-env') to see that setting the
PySystemState makes no difference in the multi-threaded environment.

-- 
Anthony Roy

[Alan]
>> Are you certain? Why not create the second and later threads with
>> another_interp = new PythonInterpreter(null,new PySystemState())
>> as recommended by Samuele in the bug report?

[Anthony]
> This makes no difference - if you look at the code in PythonInterpreter,
> it's clear that doing that simply changes the static PySystemState
> instance in the Py class - i.e. it replaces it globally.

I am looking at the code in PythonInterpreter.java.

What I see is that the systemState is kept as an instance variable of
PythonInterpreter when it is passed in, i.e. it is not shared with any
other PythonInterpreter.

Which conflicts directly with your statement "it's clear that doing
that simply changes the static PySystemState instance in the Py class
- i.e. it replaces it globally."

Are we looking at the same code? I'm looking at the source of jython
2.1, as included in the jython 2.1 download.

[Anthony]
> 1) Global variables are kept in the system state - hence different scripts
> with global variables of the same name can change the value of each
> other's variables!

Well, you can pass in a globals dictionary when creating the PythonInterpreter.

> 2) Initializing the PythonInterpreter is done through a static method -
> hence you cannot supply different scripts with different sys.argv for
> example.

This is correct. Also, you cannot supply different classloaders to
different interpreters.

[Anthony]
> Attached is a minimal example of how the global environments of completely
> different scripts interfere with each other. One Java class which sets
> each script running in a different thread, and the three pythons scripts
> which happen to have global variables in common. Run the java program with
> a command line argument (say 'new-env') to see that setting the
> PySystemState makes no difference in the multi-threaded environment.

And your example never fails for me, i.e. it never reproduces the
defective behaviour you describe.

Except that you neglected to put in the PythonInterpreter.initialize
call at the beginning of the program, so it crashes when creating new
interpreters. By adding this line to the start of your program

PythonInterpreter.initialize(System.getProperties(), null, new String[] {});

I get reliable, non-error, non-interfering behaviour every time.

Specifically, when running with threads (by supplying a command line
parameter), some variation of the following appears

New System State added.
New System State added.
New System State added.
Bernard
Melchet
Percy

Each of "Bernard", "Melchett" and "Percy" appears once and only once,
every time the code is run, without fail.

Alan.

Sounds very interesting. Anything I can reuse in the Scripting BOF  
would be great. Thanks. -Frank



On Mar 16, 2007, at 8:48 AM, Oti wrote:

> Hi all,
>
> Due date for the talk submission is getting nearer in great steps ...
> next Monday, for me.
>
> The talk (about Jython/Java integration) is making progress, but is
> not ready for upload yet.
> What took more time than expected was my decision to use a visual
> application to demonstrate the pluggability and interaction. I believe
> visual stuff is better for a demo than "just a command line".
>
> On the other hand, I (below) roughly sketched slide outlines for
>  - current development status
>  - activities around Jython
>  - Jython roadmap
>
> Please feel free to send me feedback, suggestions, in order to  
> improve those.
> And: sure I forgot important stuff...
>
> Many thanks for reviewing!
> Oti.
>
>
>
>
> <!-- slide -->
>
> Current development status
>
>  - 2.2b1 (beta) released
>  - 2.2b2 (beta) needed
>  - 2.2   (final) targeted spring 2007
>  - many 2.3 features already implemented
>  - we expect far less time to get to 2.3, compared to the 2.1 ->  
> 2.2 phase
>
>
> Note:
> Version numbers correspond to the CPython versions.
> So, for example, 2.5 Python language features probably won't work with
> Jython 2.2
>
>
>
> <!-- slide -->
>
> Jython is well and alive !
>
>  - active mailing lists
>  - slowly increasing number of committers
>  - build bots
>  - automated tests
>
> Other activities:
>  - leo user on jythonx
>  - Jim Baker and Michael Taylor on ANTLR towards 2.5
>      a parallel parser in Antlr (Groovy)
>      and a compiler targeting ASM (Groovy, under dev in JRuby)
>
>
>
> <!-- slide -->
>
> Jython Roadmap
>
> - next release will be primarily a cleanup release
>  ++ 2.3, 2.4, or even 2.5: not decided yet
>  ++ improving java integration
>
> - Jython 2.x (following release)
>  ++ performance improvements
>  ++ enable CPython frameworks ( Django ?)
>
> - Jython 3 (AKA Jython 3000)
>  ++ like CPython 3.0
>  ++ backwards incompatible
>
> see also: http://www.jython.org/Project/roadmap.html
>
>
> <!-- slide -->
>
> Getting involved:
>  - start with the wiki at http://wiki.python.org/jython/ 
> HowToGetInvolved
>  - pick an unimplemented module
>  - solve bugs from the tracker at http://sourceforge.net/projects/ 
> jython/
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>



--
Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
TestMaker: The open-source SOA test automation tool

Hi Frank, others

The slides of presentation are now online (as .pdf) here:
    http://jython.extreme.st
The examples will follow soon.

Please feel free to reuse whatever you like.
I already included a reference to your BOF in the "More information" section.

And again: Feedback is welcome !
I believe I got 2 more chances to improve the slides.

Thanks a lot,
Oti.


On 3/16/07, Frank Cohen <fcohen@...> wrote:
> Sounds very interesting. Anything I can reuse in the Scripting BOF
> would be great. Thanks. -Frank
>
>
>
> On Mar 16, 2007, at 8:48 AM, Oti wrote:
>
> > Hi all,
> >
> > Due date for the talk submission is getting nearer in great steps ...
> > next Monday, for me.
> >
> > The talk (about Jython/Java integration) is making progress, but is
> > not ready for upload yet.
> > What took more time than expected was my decision to use a visual
> > application to demonstrate the pluggability and interaction. I believe
> > visual stuff is better for a demo than "just a command line".
> >
> > On the other hand, I (below) roughly sketched slide outlines for
> >  - current development status
> >  - activities around Jython
> >  - Jython roadmap
> >
> > Please feel free to send me feedback, suggestions, in order to
> > improve those.
> > And: sure I forgot important stuff...
> >
> > Many thanks for reviewing!
> > Oti.
> >
> >
> >
> >
> > <!-- slide -->
> >
> > Current development status
> >
> >  - 2.2b1 (beta) released
> >  - 2.2b2 (beta) needed
> >  - 2.2   (final) targeted spring 2007
> >  - many 2.3 features already implemented
> >  - we expect far less time to get to 2.3, compared to the 2.1 ->
> > 2.2 phase
> >
> >
> > Note:
> > Version numbers correspond to the CPython versions.
> > So, for example, 2.5 Python language features probably won't work with
> > Jython 2.2
> >
> >
> >
> > <!-- slide -->
> >
> > Jython is well and alive !
> >
> >  - active mailing lists
> >  - slowly increasing number of committers
> >  - build bots
> >  - automated tests
> >
> > Other activities:
> >  - leo user on jythonx
> >  - Jim Baker and Michael Taylor on ANTLR towards 2.5
> >      a parallel parser in Antlr (Groovy)
> >      and a compiler targeting ASM (Groovy, under dev in JRuby)
> >
> >
> >
> > <!-- slide -->
> >
> > Jython Roadmap
> >
> > - next release will be primarily a cleanup release
> >  ++ 2.3, 2.4, or even 2.5: not decided yet
> >  ++ improving java integration
> >
> > - Jython 2.x (following release)
> >  ++ performance improvements
> >  ++ enable CPython frameworks ( Django ?)
> >
> > - Jython 3 (AKA Jython 3000)
> >  ++ like CPython 3.0
> >  ++ backwards incompatible
> >
> > see also: http://www.jython.org/Project/roadmap.html
> >
> >
> > <!-- slide -->
> >
> > Getting involved:
> >  - start with the wiki at http://wiki.python.org/jython/
> > HowToGetInvolved
> >  - pick an unimplemented module
> >  - solve bugs from the tracker at http://sourceforge.net/projects/
> > jython/
> >
> > ----------------------------------------------------------------------
> > ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?
> > page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Jython-dev mailing list
> > Jython-dev@...
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>
>
>
> --
> Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
> TestMaker: The open-source SOA test automation tool
>
>
>
>

Hi again,

In order to not offend any copyrights, I'll rewrite the draft.
Please stay tuned.

Oti.

On 3/20/07, Oti <ohumbel@...> wrote:
> Hi Frank, others
>
> The slides of presentation are now online (as .pdf) here:
>     http://jython.extreme.st
> The examples will follow soon.
>
> Please feel free to reuse whatever you like.
> I already included a reference to your BOF in the "More information" section.
>
> And again: Feedback is welcome !
> I believe I got 2 more chances to improve the slides.
>
> Thanks a lot,
> Oti.
>
>
> On 3/16/07, Frank Cohen <fcohen@...> wrote:
> > Sounds very interesting. Anything I can reuse in the Scripting BOF
> > would be great. Thanks. -Frank
> >
> >
> >
> > On Mar 16, 2007, at 8:48 AM, Oti wrote:
> >
> > > Hi all,
> > >
> > > Due date for the talk submission is getting nearer in great steps ...
> > > next Monday, for me.
> > >
> > > The talk (about Jython/Java integration) is making progress, but is
> > > not ready for upload yet.
> > > What took more time than expected was my decision to use a visual
> > > application to demonstrate the pluggability and interaction. I believe
> > > visual stuff is better for a demo than "just a command line".
> > >
> > > On the other hand, I (below) roughly sketched slide outlines for
> > >  - current development status
> > >  - activities around Jython
> > >  - Jython roadmap
> > >
> > > Please feel free to send me feedback, suggestions, in order to
> > > improve those.
> > > And: sure I forgot important stuff...
> > >
> > > Many thanks for reviewing!
> > > Oti.
> > >
> > >
> > >
> > >
> > > <!-- slide -->
> > >
> > > Current development status
> > >
> > >  - 2.2b1 (beta) released
> > >  - 2.2b2 (beta) needed
> > >  - 2.2   (final) targeted spring 2007
> > >  - many 2.3 features already implemented
> > >  - we expect far less time to get to 2.3, compared to the 2.1 ->
> > > 2.2 phase
> > >
> > >
> > > Note:
> > > Version numbers correspond to the CPython versions.
> > > So, for example, 2.5 Python language features probably won't work with
> > > Jython 2.2
> > >
> > >
> > >
> > > <!-- slide -->
> > >
> > > Jython is well and alive !
> > >
> > >  - active mailing lists
> > >  - slowly increasing number of committers
> > >  - build bots
> > >  - automated tests
> > >
> > > Other activities:
> > >  - leo user on jythonx
> > >  - Jim Baker and Michael Taylor on ANTLR towards 2.5
> > >      a parallel parser in Antlr (Groovy)
> > >      and a compiler targeting ASM (Groovy, under dev in JRuby)
> > >
> > >
> > >
> > > <!-- slide -->
> > >
> > > Jython Roadmap
> > >
> > > - next release will be primarily a cleanup release
> > >  ++ 2.3, 2.4, or even 2.5: not decided yet
> > >  ++ improving java integration
> > >
> > > - Jython 2.x (following release)
> > >  ++ performance improvements
> > >  ++ enable CPython frameworks ( Django ?)
> > >
> > > - Jython 3 (AKA Jython 3000)
> > >  ++ like CPython 3.0
> > >  ++ backwards incompatible
> > >
> > > see also: http://www.jython.org/Project/roadmap.html
> > >
> > >
> > > <!-- slide -->
> > >
> > > Getting involved:
> > >  - start with the wiki at http://wiki.python.org/jython/
> > > HowToGetInvolved
> > >  - pick an unimplemented module
> > >  - solve bugs from the tracker at http://sourceforge.net/projects/
> > > jython/
> > >
> > > ----------------------------------------------------------------------
> > > ---
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> > > share your
> > > opinions on IT & business topics through brief surveys-and earn cash
> > > http://www.techsay.com/default.php?
> > > page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Jython-dev mailing list
> > > Jython-dev@...
> > > https://lists.sourceforge.net/lists/listinfo/jython-dev
> > >
> >
> >
> >
> > --
> > Frank Cohen, PushToTest, http://www.PushToTest.com, phone 408 374 7426
> > TestMaker: The open-source SOA test automation tool
> >
> >
> >
> >
>

You will first need to have Java runtime installed on your machine.  You 
can download the Java runtime by following links on http://java.sun.com 
and then you can install Jython by following the installation notes on 
the Jython site: http://www.jython.org/Project/installation.html

Josh

Alain Morque wrote:
> Hi,
>
> i have just downloaded jython2.1 
> The result file is jython_installer-2.2b1.jar
>
> The installation guide doesn't corresponds to this file ( no.class)
>
> i have no skill on Java. How to install jython with this .jar ? 
>
> Thanks
>
> Regards
>
> Alain MORQUE
> Office phone: (33) (0) 4.92.11.66.19, Fax (33) (0) 4.93.24.70.02, 
> Extension 36 6619
> Email : MORQUEA@..., alain.morque@... 
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>

[James Abley]
> I have a stream of consciousness regarding unicodedata that I'd like
> to put somewhere other than my head!

That's exactly the kind of information that I had in mind.  It's all
fresh in your mind, now that you're implementing it. If it's captured
on a unicodedata specific page, then that page becomes

1. A collection point for the kind of research information that
doesn't belong in code
2. A starting point for potential users to decide whether or not the
module will match their requirements.
3. A starting point for other implementors who want to
extend/improve/correct the existing functionality.

As an example of the kind of thing I mean, see this page about socket timeouts

http://www.xhaus.com/alan/python/timeout.html

> Is this an existing resource that we're extending, or a request for
> something new?

Well, it could be either I suppose.

The existing FAQ infrastructure could be used, although I think that
the kind of detail I have in mind is too much detail for that FAQ. For
example, how could we map all of the details from the above socket
timeouts page to the existing FAQ?

http://www.jython.org/cgi-bin/faqw.py?req=index

What I would really like to see is a whole wiki page dedicated to each
module, so that it could be as detailed as the socket page above.

In terms of infrastructure and maintence, it would only be a single
wiki instance, e.g. MoinMoin, which is already used extensively on the
python.org.

If this doesn't happen, the I do recommend that you write up your
implementation details on a page like the one above, and host it
somewhere yourself. It might not be centralised on the jython web
site, but at least it will turn up in search engines.

Regards,

Alan.

I think the existing Jython wiki would serve this purpose pretty well.
 Create a top level page "Modules", link to it from the users section
of http://wiki.python.org/jython/FrontPage and add pages off of it for
each module you want to document.  I imagine the pieces of information
that trickle in for each module will be different enough that coming
up with some faq structure or system doesn't make sense.

Charlie

On 3/10/07, Alan Kennedy <jython-dev@...> wrote:
> [James Abley]
> > I have a stream of consciousness regarding unicodedata that I'd like
> > to put somewhere other than my head!
>
> That's exactly the kind of information that I had in mind.  It's all
> fresh in your mind, now that you're implementing it. If it's captured
> on a unicodedata specific page, then that page becomes
>
> 1. A collection point for the kind of research information that
> doesn't belong in code
> 2. A starting point for potential users to decide whether or not the
> module will match their requirements.
> 3. A starting point for other implementors who want to
> extend/improve/correct the existing functionality.
>
> As an example of the kind of thing I mean, see this page about socket timeouts
>
> http://www.xhaus.com/alan/python/timeout.html
>
> > Is this an existing resource that we're extending, or a request for
> > something new?
>
> Well, it could be either I suppose.
>
> The existing FAQ infrastructure could be used, although I think that
> the kind of detail I have in mind is too much detail for that FAQ. For
> example, how could we map all of the details from the above socket
> timeouts page to the existing FAQ?
>
> http://www.jython.org/cgi-bin/faqw.py?req=index
>
> What I would really like to see is a whole wiki page dedicated to each
> module, so that it could be as detailed as the socket page above.
>
> In terms of infrastructure and maintence, it would only be a single
> wiki instance, e.g. MoinMoin, which is already used extensively on the
> python.org.
>
> If this doesn't happen, the I do recommend that you write up your
> implementation details on a page like the one above, and host it
> somewhere yourself. It might not be centralised on the jython web
> site, but at least it will turn up in search engines.
>
> Regards,
>
> Alan.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

[James Abley]
> I have a stream of consciousness regarding unicodedata that I'd like
> to put somewhere other than my head!

That's exactly the kind of information that I had in mind.  It's all
fresh in your mind, now that you're implementing it. If it's captured
on a unicodedata specific page, then that page becomes

1. A collection point for the kind of research information that
doesn't belong in code
2. A starting point for potential users to decide whether or not the
module will match their requirements.
3. A starting point for other implementors who want to
extend/improve/correct the existing functionality.

As an example of the kind of thing I mean, see this page about socket timeouts

http://www.xhaus.com/alan/python/timeout.html

> Is this an existing resource that we're extending, or a request for
> something new?

Well, it could be either I suppose.

The existing FAQ infrastructure could be used, although I think that
the kind of detail I have in mind is too much detail for that FAQ. For
example, how could we map all of the details from the above socket
timeouts page to the existing FAQ?

http://www.jython.org/cgi-bin/faqw.py?req=index

What I would really like to see is a whole wiki page dedicated to each
module, so that it could be as detailed as the socket page above.

In terms of infrastructure and maintence, it would only be a single
wiki instance, e.g. MoinMoin, which is already used extensively on the
python.org.

If this doesn't happen, the I do recommend that you write up your
implementation details on a page like the one above, and host it
somewhere yourself. It might not be centralised on the jython web
site, but at least it will turn up in search engines.

Regards,

Alan.