jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)

[Jython-dev] Difference in exception raised when compiled vs. interpreted

[Titus B. <ti...@ca...>]

Hi, I'm having an interesting problem:

in the following piece of code, when interpreted,

---
try:
   (a, b, c) = string.split(s)
except ValueError:
   print 'ERROR in input string, skipping line: %s' % (s,)
--

if the split of s does not contain three elements, a ValueError
is raised & caught appropriately.

HOWEVER, if I use jythonc to compile the file into a .class, it turns
out that a KeyError is raised in the same place for the same piece of
code.

I then need to change the except statement to:

--
except (ValueError, KeyError):
--

and it all works fine.

Cheers,
--titus

Re: [Jython-dev] Jython 2.1a3 on j2sdk1.4.0beta

[Titus B. <ti...@ca...>]

-> (another question which doesn't belong here)
-> I would also like to change Zope such that it uses
-> generators.  The problem we are (or will be) running
-> into is the large process size of the ZServers. 
-> Basically, every time one uses objectValues() the
-> entire contents of the directory is loaded into memory
-> and values placed into a list.  I would like to skip
-> zope 2.4.0 based on python 2.1 and go directly to
-> 2.2a1 so that I could start this migration.  The
-> content management system will be pushing Zope to it
-> limits.  Use of memory has been rather cavalier in
-> Zope world cause we think it is cheap and plentiful. 
-> However, reading 200,000 bulky objects into memory
-> (magnified by 1000 users) is not ideal behavior when
-> an iterator could be used instead and retrieve only
-> one object at a time.

A problem that I've been running into wrt Java is the JVM hard memory limit.
Since users can (try to) load essentially arbitrary amounts of data into
my GUI app, we need to set the maximum heap size of Java at an absurd
place for *all* runs.

I don't have comparisons yet -- someone has been thinking about rewriting
various portions of my Jython app in wxPython -- but it seems to me like
Jython and Java together are using outlandish amounts of memory.  Something
to think about wrt Zope...

--t

[Jython-dev] building from cvs

[Brian P. <bp...@wi...>]

Hi,

I'm trying to build from src.  I have installed javacc2.0.  And I have
changed the 'build.xml' to make sure this property is set:
<property name="javaccHome" value="C:/A_temp/java_cc/javacc2.0/bin/lib"
/>

Here is the output from running ant:
<snip>
C:\A_temp\cvs_projects\jython\jython>ant
Buildfile: build.xml

init:

prepare:

tree:

BUILD FAILED

C:\A_temp\cvs_projects\jython\jython\build.xml:45: Javacchome not set.
</snip>

I tried setting 'javacchome' as an environment variable also, to no
avail.

Any help would be greatly appreciated.

Brian

[Jython-dev] Jython 2.1a3 on j2sdk1.4.0beta

[john c. <joh...@ya...>]

I've been running Jython on j2sdk1.4.0beta.  Haven't
had any issues yet.  Been writing an Acquisition
Implicit module (in Jython, 30 lines of code).  Next
is to use the nio modules to create a medusa of sorts.

I would really like to rewrite Zope to run on Java
since java has true threads and a bunch of third party
software (an really cool one that comes to mind EOF). 
I have a feeling that a Zope on Java would be far more
appealing to consumers since now a whole universe of
software is available  Java and Jython have a
wonderful interchangebly which is quite amazing.

(another question which doesn't belong here)
I would also like to change Zope such that it uses
generators.  The problem we are (or will be) running
into is the large process size of the ZServers. 
Basically, every time one uses objectValues() the
entire contents of the directory is loaded into memory
and values placed into a list.  I would like to skip
zope 2.4.0 based on python 2.1 and go directly to
2.2a1 so that I could start this migration.  The
content management system will be pushing Zope to it
limits.  Use of memory has been rather cavalier in
Zope world cause we think it is cheap and plentiful. 
However, reading 200,000 bulky objects into memory
(magnified by 1000 users) is not ideal behavior when
an iterator could be used instead and retrieve only
one object at a time.

Any thoughts or comments, please contact me.
-john

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

[Jython-dev] [ jython-Patches-447006 ] Fix NPE in PyString constructor

[<no...@so...>]

Patches item #447006, was opened at 2001-08-01 17:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=447006&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryn Keller (xoltar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix NPE in PyString constructor

Initial Comment:
PyString currently doesn't check that the passed-in
String is non-null, so you only find out later when you
try to use the PyString for something (__len__, for
instance). This patch handles the problem by throwing
an IllegalArgumentException when the null is passed.
Another option might be to silently convert the null to
an empty String.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=447006&group_id=12867

Re: [Jython-dev] Pickling for PyMetaClass

[Kevin D. <kda...@we...>]

Good news. A bit of reading through cPickle.c and cPickle.java showed me the
way. ExtensionClass.c does, in fact, use reduce, and I discovered that
load_reduce looks for __basicnew__ if the args tuple is None. So, that all
works fine. (see below...)

> > With a small patch to __builtin__.type(), we can get around this:
> >
> >     public static PyClass type(PyObject o) {
> >         if (o instanceof PyInstance) {
> >             return PyJavaClass.lookup(o.getClass());
> >         } else {
> >             return o.__class__;
> >         }
> >     }
> >
> > (replacing PyJavaClass.lookup(PyInstance.class) with
> > PyJavaClass.lookup(o.getClass())
> Yes, I see the point. I should admit that I feel a bit uncomfortable
> with this design driven by the matter of events and without a whole
> picture. But the patch can go in with the same transitional status
> of the PyMetaClass hook. See below ...

This patch is necessary to support user-defined Instance classes and
pickling... It looks like no other change is needed for this to work,
though.

Kevin

Re: [Jython-dev] Does Jython support the Java threading model or the cPython threading model?

[Ype K. <yk...@xs...>]

John,

>I have not yet been able to find an answer to this
>question.  I understand that the development aim
>behind Jython is to be closely matched to cPython.
>However, this would be an interesting place for Jython
>to diverge from cPython.
>
>CPython implements a global interpreter lock which
>prevents multiple threads from running on multiple
>CPUs.  A single multi-threaded cPython process makes
>little use of the extra processing horsepower
>available on enterprise class SMP server
>configurations.
>
>The java threading model supports both OS native
>threads and "green" threads depending on the JVM used.
> If Jython is based on the Java threading model.  With
>a fair degree of good software design, it is actually
>possible for a multi-threaded Jython process to run
>faster than the corresponding cPython process.  So the
>factor 2 which comes up so frequently when comparing
>the speed of Jython to cPython is somewhat irrelevant
>and largely depends on the context of which it is
>used.
>
>If Jython is based on the Java threading model, a
>server comprised of 4 CPUs could potentially out pace
>the cPython process by a factor of 2.  I feel this is
>a very important distinction between the two varieties
>of python, and for enterprise class systems, the use
>of Jython may be preferred.

Have a look at PyThread.java in the sources (org.python.core iirc)
and admire its simplicity: Python's threading model
is pretty close to Java's, and this is no coincidence.
Most of what it does is overriding java.lang.Thread.run()
to call the python function provided
as argument to the python standard function to start a new thread.
This makes Jython threading as good as the threading provided
by the JVM you are using. When the JVM uses multiprocessor
threading, so will Jython.

There are a few small differences, ao. you cannot catch
java.lang.InterruptedException in Jython and Python threads
should end in system.exit(), which throws a Python exception.
Also you may have to register (atexit module) a Python exit function
that calls the JVM exit function from java.lang.RunTime.

Have fun,
Ype

P.S. Installing the sources is an option in the installer that
will add the org directory to your installation. Default is off,
which is a pity I think.

Re: [Jython-dev] Does Jython support the Java threading model or the cPython threading model?

[Titus B. <ti...@ca...>]

-> I have not yet been able to find an answer to this
-> question.  I understand that the development aim
-> behind Jython is to be closely matched to cPython. 
-> However, this would be an interesting place for Jython
-> to diverge from cPython.

;) Jython runs on Java, and hence "supports" the Java
threading model, as far as I know.

--titus

[Jython-dev] Does Jython support the Java threading model or the cPython threading model?

[john c. <joh...@ya...>]

I have not yet been able to find an answer to this
question.  I understand that the development aim
behind Jython is to be closely matched to cPython. 
However, this would be an interesting place for Jython
to diverge from cPython.

CPython implements a global interpreter lock which
prevents multiple threads from running on multiple
CPUs.  A single multi-threaded cPython process makes
little use of the extra processing horsepower
available on enterprise class SMP server
configurations.

The java threading model supports both OS native
threads and "green" threads depending on the JVM used.
 If Jython is based on the Java threading model.  With
a fair degree of good software design, it is actually
possible for a multi-threaded Jython process to run
faster than the corresponding cPython process.  So the
factor 2 which comes up so frequently when comparing
the speed of Jython to cPython is somewhat irrelevant
and largely depends on the context of which it is
used.

If Jython is based on the Java threading model, a
server comprised of 4 CPUs could potentially out pace
the cPython process by a factor of 2.  I feel this is
a very important distinction between the two varieties
of python, and for enterprise class systems, the use
of Jython may be preferred.

I am an avid Jython user.  Jython has a way of making
Java seem very simple.  I'm impatient and like to get
to the point of things quickly. I am currently using
Jython in conjunction with the java accessibility
package.  I find it extremely indispensable since I
can run the program I want to interface from the
interpreter by calling main, then poke around at the
interpreter prompt.  It's a very powerful tool.

John Coppola
joh...@ya...

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [Jython-dev] Pickling for PyMetaClass

[Kevin D. <kda...@we...>]

----- Original Message -----
From: "Samuele Pedroni" <pe...@in...>
To: <jyt...@li...>; <kda...@we...>
Sent: Monday, July 30, 2001 2:39 PM
Subject: Re: [Jython-dev] Pickling for PyMetaClass


> > >             if (args.length == 0 && klass.getClass() == PyClass &&
> > >                         klass.__findattr__("__getinitargs__") == null)
{
> > >                 value = new PyInstance((PyClass)klass);
> > >             } else {
> > >                 value = klass.__call__(args);
> > >             }
> > > I will fix that.
> >
> > Hmm. Not sure I understand why the change is needed. (That should be
> > PyClass.class, right?)
> Right, OTOH this fixes a bug but don't solve your problem, I know.

Ahh... now I see why your patch would be useful for the metaclasses. I'll
think some more about if there's an approach that doesn't involve specific
references to PyMetaClass.

> > > OTOH I have briefly looked at ExtensionClasses and it seems that this
> > drives pickling through
> > > __reduce__ (is that correct?)
> > >
> > > so I suggest to use the same technique for the moment also in Jython,
> > > if you encounter any problem/bug trying to do this let me know.
> >
> > Yes, I think you are correct. It looks like C ExtensionClass uses
> > __reduce__. I tried adding __reduce__ to my package, but it never gets
> > called. The EClasses and EInstances look (to the cPickle module) just
like
> > PyClasses and PyInstances, so it never gets past the call to save_type.
> >
> > With a small patch to __builtin__.type(), we can get around this:
> >
> >     public static PyClass type(PyObject o) {
> >         if (o instanceof PyInstance) {
> >             return PyJavaClass.lookup(o.getClass());
> >         } else {
> >             return o.__class__;
> >         }
> >     }
> >
> > (replacing PyJavaClass.lookup(PyInstance.class) with
> > PyJavaClass.lookup(o.getClass())
> Yes, I see the point. I should admit that I feel a bit uncomfortable
> with this design driven by the matter of events and without a whole
> picture. But the patch can go in with the same transitional status
> of the PyMetaClass hook. See below ...

It is true that PyMetaClass is transitional... It seems like there would
always be some value to being able to subclass PyClass and PyInstance to
extend the behavior of those objects (for things like the __of__ protocol).
In order for that to generally work, it would seem that it would be useful
to use code that doesn't rely on PyClass and PyInstance specifically, but
rather instanceof PyClass and PyInstance.

> > While there is a reduce in the CExtensionClass
> > package, the resulting pickles don't really look like "reduced" pickles.
> >
> > In CPython I get something like this:
> >
> > cectest
> > Point
> > (small amount of binary data in which x, y, and foo show up.)
> >
> > Basically, it's an ectest.Point object which has values for x, y and
foo.
> >
> > My __reduce__ returns:
> > (<jextension class ectest.Point at 1491648>, (), {'y': 3, 'x': 2, 'foo':
> > 42})
> >
> > type(Point) returns org.python.PyClass
> This is strange, any idea why you get this  instead of your derived
> class?

I did that on purpose. I don't think I need to do anything to make the class
itself pickle, so I just left __class__ as org.python.core.PyClass. It's the
instances that I'm really focusing on.

(If I *did* change the class' __class__, I would have had to make a reduce
method and would have gotten an even larger difference from the CPython
cPickle.)

[snip]

> > > I agree that something similar to your proposal for pickling make
sense
> > wrt to Java idioms
> > > and PyMetaClass but the latter has a somehow transitory status (for
the
> > time being)
> > > so I prefer not to add further related/dependent code to Jython.
> >
> > I understand. I haven't been following the Python development
timeline...
> > any idea how long it will be until 2.2's semantics are finalized?
>
> It seems that to make things work I should add code :(.

I'll keep looking to see if I can figure out the difference in behavior. If
cPickle.c doesn't make special allowances for ExtensionClasses, it seems
like it should be possible to make cPickle.java do the same.

> About 2.2 semantics, I think their are mostly finalized on CPython side.
> OTOH I promised GvR to do a revision wrt Jython implications.
> In any case it will not be implemented in Jython very soon - we should
> finish 2.1 - and it's a lot of work because adding that without
refactorising
> the old Jython stuff will produce just a mess.

Agreed. There are some significant changes proposed in the PEPs.

Thanks for the feedback.

Kevin

Re: [Jython-dev] Pickling for PyMetaClass

[Samuele P. <pe...@in...>]

> > Hi,
> >
> > I have studied a bit the situation comparing
> > pickle, CPython cPickle  and Jython cPickle
> >
> > the only bug/difference that I found (related to you issue) is that
> >
> >             if (args.length == 0 && klass instanceof PyClass &&
> >                         klass.__findattr__("__getinitargs__") == null) {
> >                 value = new PyInstance((PyClass)klass);
> >             } else {
> >                 value = klass.__call__(args);
> >             }
> >
> > should be:
> >
> >             if (args.length == 0 && klass.getClass() == PyClass &&
> >                         klass.__findattr__("__getinitargs__") == null) {
> >                 value = new PyInstance((PyClass)klass);
> >             } else {
> >                 value = klass.__call__(args);
> >             }
> > I will fix that.
> 
> Hmm. Not sure I understand why the change is needed. (That should be
> PyClass.class, right?)
Right, OTOH this fixes a bug but don't solve your problem, I know.


> > OTOH I have briefly looked at ExtensionClasses and it seems that this
> drives pickling through
> > __reduce__ (is that correct?)
> >
> > so I suggest to use the same technique for the moment also in Jython,
> > if you encounter any problem/bug trying to do this let me know.
> 
> Yes, I think you are correct. It looks like C ExtensionClass uses
> __reduce__. I tried adding __reduce__ to my package, but it never gets
> called. The EClasses and EInstances look (to the cPickle module) just like
> PyClasses and PyInstances, so it never gets past the call to save_type.
> 
> With a small patch to __builtin__.type(), we can get around this:
> 
>     public static PyClass type(PyObject o) {
>         if (o instanceof PyInstance) {
>             return PyJavaClass.lookup(o.getClass());
>         } else {
>             return o.__class__;
>         }
>     }
> 
> (replacing PyJavaClass.lookup(PyInstance.class) with
> PyJavaClass.lookup(o.getClass())
Yes, I see the point. I should admit that I feel a bit uncomfortable
with this design driven by the matter of events and without a whole
picture. But the patch can go in with the same transitional status
of the PyMetaClass hook. See below ...


> While there is a reduce in the CExtensionClass
> package, the resulting pickles don't really look like "reduced" pickles.
> 
> In CPython I get something like this:
> 
> cectest
> Point
> (small amount of binary data in which x, y, and foo show up.)
> 
> Basically, it's an ectest.Point object which has values for x, y and foo.
> 
> My __reduce__ returns:
> (<jextension class ectest.Point at 1491648>, (), {'y': 3, 'x': 2, 'foo':
> 42})
> 
> type(Point) returns org.python.PyClass
This is strange, any idea why you get this  instead of your derived
class?

> 
> The pickle I get is:
> cectest
> Point
> q cectest
> Point
> (binary data in which all of the variables show up 4 times)
> 
> My original patch produced output very similar to what you get from CPython.
> I'll keep looking at cPickle and ExtensionClass to see if there's some bit
> of behavior I'm missing...
Possible, because up to the bug and type() behavior CPython and Jython
cPickle code seem to do the same thing...

> >
> > I agree that something similar to your proposal for pickling make sense
> wrt to Java idioms
> > and PyMetaClass but the latter has a somehow transitory status (for the
> time being)
> > so I prefer not to add further related/dependent code to Jython.
> 
> I understand. I haven't been following the Python development timeline...
> any idea how long it will be until 2.2's semantics are finalized?

It seems that to make things work I should add code :(.
About 2.2 semantics, I think their are mostly finalized on CPython side.
OTOH I promised GvR to do a revision wrt Jython implications.
In any case it will not be implemented in Jython very soon - we should
finish 2.1 - and it's a lot of work because adding that without refactorising
the old Jython stuff will produce just a mess.

regards, Samuele Pedroni.

Re: [Jython-dev] Pickling for PyMetaClass

[Kevin D. <kda...@we...>]

Hi,

(comments below)

----- Original Message -----
From: "Samuele Pedroni" <pe...@in...>
To: <jyt...@li...>; <kda...@we...>
Sent: Monday, July 30, 2001 9:56 AM
Subject: Re: [Jython-dev] Pickling for PyMetaClass


> Hi,
>
> I have studied a bit the situation comparing
> pickle, CPython cPickle  and Jython cPickle
>
> the only bug/difference that I found (related to you issue) is that
>
>             if (args.length == 0 && klass instanceof PyClass &&
>                         klass.__findattr__("__getinitargs__") == null) {
>                 value = new PyInstance((PyClass)klass);
>             } else {
>                 value = klass.__call__(args);
>             }
>
> should be:
>
>             if (args.length == 0 && klass.getClass() == PyClass &&
>                         klass.__findattr__("__getinitargs__") == null) {
>                 value = new PyInstance((PyClass)klass);
>             } else {
>                 value = klass.__call__(args);
>             }
> I will fix that.

Hmm. Not sure I understand why the change is needed. (That should be
PyClass.class, right?)

> OTOH I have briefly looked at ExtensionClasses and it seems that this
drives pickling through
> __reduce__ (is that correct?)
>
> so I suggest to use the same technique for the moment also in Jython,
> if you encounter any problem/bug trying to do this let me know.

Yes, I think you are correct. It looks like C ExtensionClass uses
__reduce__. I tried adding __reduce__ to my package, but it never gets
called. The EClasses and EInstances look (to the cPickle module) just like
PyClasses and PyInstances, so it never gets past the call to save_type.

With a small patch to __builtin__.type(), we can get around this:

    public static PyClass type(PyObject o) {
        if (o instanceof PyInstance) {
            return PyJavaClass.lookup(o.getClass());
        } else {
            return o.__class__;
        }
    }

(replacing PyJavaClass.lookup(PyInstance.class) with
PyJavaClass.lookup(o.getClass())

While there is a reduce in the CExtensionClass
package, the resulting pickles don't really look like "reduced" pickles.

In CPython I get something like this:

cectest
Point
(small amount of binary data in which x, y, and foo show up.)

Basically, it's an ectest.Point object which has values for x, y and foo.

My __reduce__ returns:
(<jextension class ectest.Point at 1491648>, (), {'y': 3, 'x': 2, 'foo':
42})

type(Point) returns org.python.PyClass

The pickle I get is:
cectest
Point
q cectest
Point
(binary data in which all of the variables show up 4 times)

My original patch produced output very similar to what you get from CPython.
I'll keep looking at cPickle and ExtensionClass to see if there's some bit
of behavior I'm missing...

>
> I agree that something similar to your proposal for pickling make sense
wrt to Java idioms
> and PyMetaClass but the latter has a somehow transitory status (for the
time being)
> so I prefer not to add further related/dependent code to Jython.

I understand. I haven't been following the Python development timeline...
any idea how long it will be until 2.2's semantics are finalized?

Kevin

Re: [Jython-dev] Pickling for PyMetaClass

[Samuele P. <pe...@in...>]

Hi,

I have studied a bit the situation comparing 
pickle, CPython cPickle  and Jython cPickle

the only bug/difference that I found (related to you issue) is that

            if (args.length == 0 && klass instanceof PyClass &&
                        klass.__findattr__("__getinitargs__") == null) {
                value = new PyInstance((PyClass)klass);
            } else {
                value = klass.__call__(args);
            }
            
should be:

            if (args.length == 0 && klass.getClass() == PyClass &&
                        klass.__findattr__("__getinitargs__") == null) {
                value = new PyInstance((PyClass)klass);
            } else {
                value = klass.__call__(args);
            }
I will fix that.
            
OTOH I have briefly looked at ExtensionClasses and it seems that this drives pickling through
__reduce__ (is that correct?)

so I suggest to use the same technique for the moment also in Jython,
if you encounter any problem/bug trying to do this let me know.

I agree that something similar to your proposal for pickling make sense wrt to Java idioms
and PyMetaClass but the latter has a somehow transitory status (for the time being)
so I prefer not to add further related/dependent code to Jython.

regards, Samuele Pedroni.

[Jython-dev] [ jython-Patches-444911 ] #444292 local var binding overrides fix

[<no...@so...>]

Patches item #444911, was opened at 2001-07-26 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: #444292 local var binding overrides fix

Initial Comment:
This should do the job.
! not tested ...

----------------------------------------------------------------------

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-29 07:59

Message:
Logged In: YES 
user_id=4201

I have checked it in.


----------------------------------------------------------------------

Comment By: Finn Bock (bckfnn)
Date: 2001-07-27 11:53

Message:
Logged In: YES 
user_id=4201

Looks good. It passes all my tests. We should have done 
this ages ago. Please commit it.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 09:25

Message:
Logged In: YES 
user_id=61408

jythonc part of the new patch.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 08:54

Message:
Logged In: YES 
user_id=61408

OK, I have changed the way we compile imports <wink>.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-26 14:53

Message:
Logged In: YES 
user_id=61408

So as it is, it doesn't work. To really and correctly
solve the problem and have the same semantic as CPython
we should change the way we compile imports.

I can fix this with a quick hack, for the meantime, better 
than nothing: we gain in a direction and we lose in the 
other (wrt. to CPython comp).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

[Jython-dev] [ jython-Patches-442166 ] zipfiles on syspath.

[<no...@so...>]

Patches item #442166, was opened at 2001-07-17 14:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442166&group_id=12867

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfiles on syspath.

Initial Comment:
A patch that attempt to add some support for a 
different deployment of jython applications. Some of 
the ideas which have been discussed under the title of 
poor man freezing are included, but the patch does not 
attempt to include everything.

Here is what the patch adds:

- zip files can be added to sys.path.
- The zipfile will be kept open by the sys.path list 
by replacing the string in sys.path with a string   
subclass (SyspathArchive). The zipfile is closed by GC 
and all imported modules are unloaded.
- The zipfiles is scanned by the first import after 
adding the zip file to syspath and the result is 
always stored in cachedir.

Saving the scan result on the zipfile in cachedir is 
somewhat controversial if the goal is to create a 
fully self-contained and self-executable jython 
application. OTOH I still don't think it is a big 
problem saving the scan-index in cachedir during 
development. For a deployed application we will have 
to somehow save the scan results for all the java .jar 
files inside the applications.

When we do that, we can also add new main startup 
class which will look for the main python script name 
and other startup options in the manifest file. 


The patch does *not* attempt to:

- avoid dynamic proxy creation.
- allow importing .py files from classpath .jars
- allow importing jythonc'ed modules in the 
interpreter.
- etc.


----------------------------------------------------------------------

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-27 11:54

Message:
Logged In: YES 
user_id=4201

Applied to 2.1a3.

----------------------------------------------------------------------

Comment By: Finn Bock (bckfnn)
Date: 2001-07-22 05:54

Message:
Logged In: YES 
user_id=4201

A new version of the patch which adds support the paths 
like "myjar.jar!foo/bar". This syntax is now also used for 
the __path__ field in subpackages.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=442166&group_id=12867

[Jython-dev] [ jython-Patches-444911 ] #444292 local var binding overrides fix

[<no...@so...>]

Patches item #444911, was opened at 2001-07-26 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: #444292 local var binding overrides fix

Initial Comment:
This should do the job.
! not tested ...

----------------------------------------------------------------------

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-27 11:53

Message:
Logged In: YES 
user_id=4201

Looks good. It passes all my tests. We should have done 
this ages ago. Please commit it.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 09:25

Message:
Logged In: YES 
user_id=61408

jythonc part of the new patch.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 08:54

Message:
Logged In: YES 
user_id=61408

OK, I have changed the way we compile imports <wink>.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-26 14:53

Message:
Logged In: YES 
user_id=61408

So as it is, it doesn't work. To really and correctly
solve the problem and have the same semantic as CPython
we should change the way we compile imports.

I can fix this with a quick hack, for the meantime, better 
than nothing: we gain in a direction and we lose in the 
other (wrt. to CPython comp).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

[Jython-dev] [ jython-Patches-444911 ] #444292 local var binding overrides fix

[<no...@so...>]

Patches item #444911, was opened at 2001-07-26 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: #444292 local var binding overrides fix

Initial Comment:
This should do the job.
! not tested ...

----------------------------------------------------------------------

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 09:25

Message:
Logged In: YES 
user_id=61408

jythonc part of the new patch.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 08:54

Message:
Logged In: YES 
user_id=61408

OK, I have changed the way we compile imports <wink>.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-26 14:53

Message:
Logged In: YES 
user_id=61408

So as it is, it doesn't work. To really and correctly
solve the problem and have the same semantic as CPython
we should change the way we compile imports.

I can fix this with a quick hack, for the meantime, better 
than nothing: we gain in a direction and we lose in the 
other (wrt. to CPython comp).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

[Jython-dev] [ jython-Patches-444911 ] #444292 local var binding overrides fix

[<no...@so...>]

Patches item #444911, was opened at 2001-07-26 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: #444292 local var binding overrides fix

Initial Comment:
This should do the job.
! not tested ...

----------------------------------------------------------------------

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-27 08:54

Message:
Logged In: YES 
user_id=61408

OK, I have changed the way we compile imports <wink>.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-26 14:53

Message:
Logged In: YES 
user_id=61408

So as it is, it doesn't work. To really and correctly
solve the problem and have the same semantic as CPython
we should change the way we compile imports.

I can fix this with a quick hack, for the meantime, better 
than nothing: we gain in a direction and we lose in the 
other (wrt. to CPython comp).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Re: [Jython-dev] Correction to broken link on main page www.jython.org/index.html

[<bc...@wo...>]

[Jesper Hertel]

>There is a broken link on the main Jython page www.jython.org/index.html:
>"Jon Udell talks <http://www.byte.com/column/BYT20001214S0009> about using
>the JVM to implement other languages, among them JPython." 
>
>The URL is now http://www.byte.com/documents/s=505/BYT20001214S0006/.

Updated. Thank you for reporting this.

regards,
finn

[Jython-dev] Correction to broken link on main page www.jython.org/index.html

[Jesper H. <jh...@ma...>]

Hi Jython developers,

There is a broken link on the main Jython page www.jython.org/index.html:
"Jon Udell talks <http://www.byte.com/column/BYT20001214S0009> about using
the JVM to implement other languages, among them JPython." 

The URL is now http://www.byte.com/documents/s=505/BYT20001214S0006/.


Best regards, 

Jesper Hertel 
System Developer 
Forlaget Magnus A/S 
Denmark 
jh...@ma... 

[Jython-dev] [ jython-Patches-444911 ] #444292 local var binding overrides fix

[<no...@so...>]

Patches item #444911, was opened at 2001-07-26 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: #444292 local var binding overrides fix

Initial Comment:
This should do the job.
! not tested ...

----------------------------------------------------------------------

>Comment By: Samuele Pedroni (pedronis)
Date: 2001-07-26 14:53

Message:
Logged In: YES 
user_id=61408

So as it is, it doesn't work. To really and correctly
solve the problem and have the same semantic as CPython
we should change the way we compile imports.

I can fix this with a quick hack, for the meantime, better 
than nothing: we gain in a direction and we lose in the 
other (wrt. to CPython comp).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

[Jython-dev] [ jython-Patches-444911 ] #444292 local var binding overrides fix

[<no...@so...>]

Patches item #444911, was opened at 2001-07-26 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: #444292 local var binding overrides fix

Initial Comment:
This should do the job.
! not tested ...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=312867&aid=444911&group_id=12867

Re: [Jython-dev] Re: [jython-dev]: how to use sys.path; renaming package dirs

[<bc...@wo...>]

[Ype Kingma]

>Under jython 21a2, Java 1.1.8, OS2
>
>  os.path.dirname('e:\\pyp\\pqp/pqdb.py' )
>
>gives:
>
>  'e:\\pyp'
>
>but I expected pqp to be part of the result.
>Obviously this is different from your result, so
>the OS seems to have influence here.

It is more likely a java1/java2 thing. Both on windows:

Jython 2.1a2 on java1.4.0-beta (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from java.io import File
>>> f = File('e:\\pyp\\pqp/pqdb.py')
>>> f
e:\pyp\pqp\pqdb.py
>>>

Jython 2.1a2 on java1.1.7A (JIT: symcjit)
Type "copyright", "credits" or "license" for more information.
>>> from java.io import File
>>> f = File('e:\\pyp\\pqp/pqdb.py')
>>> f
e:\pyp\pqp/pqdb.py
>>>

I'm not quite convinced that jython should try to worm around this issue
in dirname. Can't you fix the problem at its origin by using os.sep and
os.path.join to create the path?


>I tried to find how this influence is programmed
>into the jython environment, but I could not find it
>because module os is written in java, but it does not
>seem to have a special provision for os.path.

The "os" is just renaming the Lib/javaos.py file. 
os.path is loaded from Lib/javapath.py

>On renaming package dirs (see previous post):
>
>The module attribute __file__ contains the old path
>name for an imported compiled module, which is
>no more correct when the package and package directory
>have been renamed.

It seems to match CPython on this point.

regards,
finn

[Jython-dev] Re: [jython-dev]: how to use sys.path; renaming package dirs

[Ype K. <yk...@xs...>]

Finn,

Under jython 21a2, Java 1.1.8, OS2

  os.path.dirname('e:\\pyp\\pqp/pqdb.py' )

gives:

  'e:\\pyp'

but I expected pqp to be part of the result.
Obviously this is different from your result, so
the OS seems to have influence here.

I tried to find how this influence is programmed
into the jython environment, but I could not find it
because module os is written in java, but it does not
seem to have a special provision for os.path.

On renaming package dirs (see previous post):

The module attribute __file__ contains the old path
name for an imported compiled module, which is
no more correct when the package and package directory
have been renamed.

Regards,
Ype

Re: [Jython-dev] __builtins__ support (with patch)

[Samuele P. <pe...@in...>]

Hi.

> 
> Samuele,
> 
> The primary reason is that I have some legacy code that uses 
> __builtins__ that I would rather not
> have to rewrite. It's an application maintain by another party and I 
> don't want to have to continually
> sync with their copy.
> 
> In addition, there are some neat things you can do, like dynamically 
> being able to re-define the behavior of builtin functions and add new 
> builtins...
I see
 
> The patch seems to be sound, and I don't understand why it's hitting 
> those null frames in the current CVS, so any ideas would be appreciated.
> 
If the goals are those stated above the patch seems far from complete or correct.
See CPython (as starting point):
 Objects/frameobject.c 
 Python/import.c (PyImport_ExecCodeModuleEx)
and compare with:
org.python.core.PyFrame
and where PyFrames are created and module execution code (in org.python.core.Py and imp)

Both the place PyModule and the approach (__import__) are probably wrong.

That's just the result of a quick survey of Jython and CPython code (it's not the whole picture).

OTOH python __builtins__ is related to restricted execution, a thing that jython won't implement.
See Jython vs CPython in the doc.

The problem with the null frames is different, that should be solved anyway.

regards, Samuele Pedroni.