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

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

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

Hi.

[Finn]
> Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
> Type "copyright", "credits" or "license" for more information.
> >>> import pack1
> >>> print pack1.Node, type(pack1.Node)
> pack1.Node <type 'class'>
> >>> from pack1.Node import Node
> >>> print pack1.Node, type(pack1.Node)
> <module 'pack1.Node' from 'pack1\Node.pyc'> <type 'module'>
> 
> 
> Jython 2.0alpha2 on java1.3.0 (JIT: null)
> >>> import pack1
> >>> print pack1.Node, type(pack1.Node)
> pack1.Node org.python.core.PyClass
> >>> from pack1.Node import Node
> >>> print pack1.Node, type(pack1.Node)
> pack1.Node org.python.core.PyClass
> >>>

The issue is clear to me, the cause of this is the following piece of
code that I left around  as it was:       


	if (ret != null) {
            // Allow a package component to change its own meaning
            PyObject tmp = __dict__.__finditem__(attr);
            if (tmp != null)
            ret = tmp;
            __dict__.__setitem__(attr, ret);
            return ret;
        }

Is that really necessary, I should study a little better CPython semantics.
Then I will post a fixed fix <wink>.

regards, Samuele.

Re: [Jython-dev] Second alpha release of Jython-2.0

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

On Wed, 20 Dec 2000 18:12:23 -0700, you wrote:

>At 10:28 PM 12/17/2000 +0000, Finn Bock wrote:
> >Jython-2.0a2 is now available.
> >
> >  http://jython.sourceforge.net/index.html
> >
> >Install as with Jython-2.0a1. I don't intend to announce this any
> >more widely than these lists for now.
>
>As of b2 the installer is still producing a bad jython.bat
>file on Windows systems.  It's not respecting the rule (for
>bat files) that all components of the path have to be 8 chars
>or less, so if your Java is under "Program Files" that piece
>needs to look like "Progra~1".

I would rather use quotes (aussming Robert is correct that it works
too). The remaining path which isn't fully quoted is the path to the
java.exe. Does the script work for you, if you edit jython.bat and adds
doublequotes around the path to java.exe? In my installation it becomes:

"I:\JAVA\JDK1.3\jre\bin\java.exe" "-Dpython.home...

If that is enough, I will add it to alpha 3. Let me know.

>SourceForge doesn't like me...downloads are a disaster and
>posting bugs is no better so I'm sending it here.

I think that it is just some transition pains. Lets hope it all
straigthen itself out within a short period of time.

regards,
finn

Re: [Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

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

On Thu, 21 Dec 2000 03:15:56 +0100, you wrote:

>What follows as attachment is a proposal for a patch that encompasses three
>points:
>* Solves [Bug #12624] and more generally separates (partially) the import
>logic from __findattr__
>for py modules, this will make import more compliant with CPython but keeps
>attribute-getting forced
>import working (jython idiom).
>* Makes __import__ hook effective also for the latter case of import through
>attribute getting
>  (from py packages).
>* Makes PyJavaPackage __mgr__ accessible and mutable from jython too.
>More appropriate (than __import__) "expert" hook for java pkgs/classes std
>import.
>
>Patch design:
>* A protected method PyObject impAttr(String name) is added to PyObject.
>Default impl just
>calls __findattr__(name). (Better name proposals are welcome).
>* Import logic in org.python.core.imp using __findattr__ is modified and
>calls
>impAttr instead.
>* In PyModule:
>  * (Forced) import logic in __findattr__ is moved to an impAttr impl.
>  * In the case an attribute attr is not there __findattr__ try to import it
>trough
>    __builtin__.__import__. This makes __import__ hook effective for
>attribute
>   -getting import.
>
>I will check this in eventually, but only after feedback.

The patch is fine, but in the situation where there if a name conmflict,
is looks as if CPython will change the definition of a name in a module:


Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import pack1
>>> print pack1.Node, type(pack1.Node)
pack1.Node <type 'class'>
>>> from pack1.Node import Node
>>> print pack1.Node, type(pack1.Node)
<module 'pack1.Node' from 'pack1\Node.pyc'> <type 'module'>


Jython 2.0alpha2 on java1.3.0 (JIT: null)
>>> import pack1
>>> print pack1.Node, type(pack1.Node)
pack1.Node org.python.core.PyClass
>>> from pack1.Node import Node
>>> print pack1.Node, type(pack1.Node)
pack1.Node org.python.core.PyClass
>>>

[Jython-dev] patch proposal for [Bug #126241] Import fails to find submodule etc.

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

Hi.

What follows as attachment is a proposal for a patch that encompasses three
points:
* Solves [Bug #12624] and more generally separates (partially) the import
logic from __findattr__
for py modules, this will make import more compliant with CPython but keeps
attribute-getting forced
import working (jython idiom).
* Makes __import__ hook effective also for the latter case of import through
attribute getting
  (from py packages).
* Makes PyJavaPackage __mgr__ accessible and mutable from jython too.
More appropriate (than __import__) "expert" hook for java pkgs/classes std
import.

Patch design:
* A protected method PyObject impAttr(String name) is added to PyObject.
Default impl just
calls __findattr__(name). (Better name proposals are welcome).
* Import logic in org.python.core.imp using __findattr__ is modified and
calls
impAttr instead.
* In PyModule:
  * (Forced) import logic in __findattr__ is moved to an impAttr impl.
  * In the case an attribute attr is not there __findattr__ try to import it
trough
    __builtin__.__import__. This makes __import__ hook effective for
attribute
   -getting import.

I will check this in eventually, but only after feedback.
Let me know.

regards, Samuele Pedroni.

Re: [Jython-dev] Second alpha release of Jython-2.0

[Robert W. B. <rb...@di...>]

Hello,

On Wed, 20 Dec 2000, Mats Wichmann wrote:
> At 10:28 PM 12/17/2000 +0000, Finn Bock wrote:
>  >Jython-2.0a2 is now available.
>  >
>  >  http://jython.sourceforge.net/index.html
>  >
>  >Install as with Jython-2.0a1. I don't intend to announce this any
>  >more widely than these lists for now.
> 
> As of b2 the installer is still producing a bad jython.bat
> file on Windows systems.  It's not respecting the rule (for
> bat files) that all components of the path have to be 8 chars
> or less, so if your Java is under "Program Files" that piece
> needs to look like "Progra~1".

Or enclosed in quotation marks- the other rule :)
I only mention this because I have a preference for seeing the
full path in quotes.  As someone who uses Windows only rarely, I
find this duality silly when quotes allow the perceived path and
functional path to be the same.  Or maybe I'm just easily confused :)

-Robert

Re: [Jython-dev] Second alpha release of Jython-2.0

[Mats W. <ma...@la...>]

At 10:28 PM 12/17/2000 +0000, Finn Bock wrote:
 >Jython-2.0a2 is now available.
 >
 >  http://jython.sourceforge.net/index.html
 >
 >Install as with Jython-2.0a1. I don't intend to announce this any
 >more widely than these lists for now.

As of b2 the installer is still producing a bad jython.bat
file on Windows systems.  It's not respecting the rule (for
bat files) that all components of the path have to be 8 chars
or less, so if your Java is under "Program Files" that piece
needs to look like "Progra~1".

SourceForge doesn't like me...downloads are a disaster and
posting bugs is no better so I'm sending it here.

Mats

Re: [Jython-dev] Re: [Bug #126327] Infinite recursion in subpackage import

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

Hi.

I have just checked in a patch for the bug.
Basically it's Finn idea applied inside PyModule.__findattr__  + some makeup
to this.

So we get rid of the  equivalent bug in the same setup but with p2.__init__
containing something like:

print __name__
import p1
print p1.p2.p3

regards, Samuele.

Re: [Jython-dev] FW: Jython installation problem on Mac OSX

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

[Jim Harrison]

>Jython gives the following error when attempting to install on Mac OSX (JVM
>1.2):
>
>[jhh:~] harrison% java jython-20a2
>try path /Users/harrison/
>can not get flavour null for os 'Mac_OS_X'
>exception in called method net.sourceforge.liftoff.installer.Install2.main
>java.lang.NullPointerException

I'll look into the exception tomorrow. Until a real solution is
available, you can tell the installer which operating system flavor it
should use on the command line:

   java jython-20a2 -f mac

or

   java jython-20a2 -f unix

I'm not sure which you should use. The mac flavor will not create any
startup scripts, unix will create bourne-shell scripts. I think I have
heard that Mac OSX is somewhat unix-like. Is that correct? If the unix
flavor works, please let me know.

regards,
finn

[Jython-dev] FW: Jython installation problem on Mac OSX

[Jim H. <jh...@pi...>]

Jython gives the following error when attempting to install on Mac OSX (JVM
1.2):

[jhh:~] harrison% java jython-20a2
try path /Users/harrison/
can not get flavour null for os 'Mac_OS_X'
exception in called method net.sourceforge.liftoff.installer.Install2.main
java.lang.NullPointerException
        at java.awt.GridBagLayout.GetLayoutInfo(GridBagLayout.java:808)
        at 
java.awt.GridBagLayout.preferredLayoutSize(GridBagLayout.java:564)
        at java.awt.Container.preferredSize(Container.java:643)
        at java.awt.Container.getPreferredSize(Container.java:626)
        at java.awt.Window.pack(Window.java:264)
        at 
net.sourceforge.liftoff.installer.awt.OSFlavorSelect.setupGui(OSFlavorSelect
.java:133)
        at 
net.sourceforge.liftoff.installer.awt.OSFlavorSelect.<init>(OSFlavorSelect.j
ava:58)
        at 
net.sourceforge.liftoff.installer.awt.OSFlavorSelect.showDialog(OSFlavorSele
ct.java:162)
        at 
net.sourceforge.liftoff.installer.Info.loadInstallerProps(Info.java:307)
        at 
net.sourceforge.liftoff.installer.Install2.<init>(Install2.java:92)
        at 
net.sourceforge.liftoff.installer.Install2.main(Install2.java:130)
        at java.lang.reflect.Method.invoke(Native Method)
        at jython-20a2.main(Install.java:376)
java.lang.reflect.InvocationTargetException

Installation on Mac OS 8.6 with JVM 1.18 appears to work fine, incidentally.

Jim Harrison
Univ. of Pittsburgh

RE: [Jython-dev] Second alpha release of Jython-2.0

[Tim P. <ti...@ho...>]

[Mats Wichmann]
> I'm having major trouble downloading this.  It's proceeding at
> an absolutely glacial pace, and each of my four first attempts
> in the last 24 hours aborted without downloading the whole file
> (in a way that I couldn't restart the download).

I just tried it, and it came across in 1 minute and 22 seconds.  Very
bursty, though, and for a while after the first 200Kb I thought it had
frozen.

> So far, the counter on the download page shows 0 successful
> downloads of alpha-2.  Is SourceForge going south on us (again)?

SF is running on different hardware today than it was on Friday -- they just
did a massive upgrade.  Lots of little things have indeed been flaky since
that started.  Don't know what else to say about your download woes.

Re: [Jython-dev] Second alpha release of Jython-2.0

[Mats W. <ma...@la...>]

At 10:28 PM 12/17/2000 +0000, Finn Bock wrote:
 >Jython-2.0a2 is now available.
 >
 >  http://jython.sourceforge.net/index.html
 >
 >Install as with Jython-2.0a1. I don't intend to announce this any
 >more widely than these lists for now.


I'm having major trouble downloading this.  It's proceeding at
an absolutely glacial pace, and each of my four first attempts
in the last 24 hours aborted without downloading the whole file
(in a way that I couldn't restart the download).

So far, the counter on the download page shows 0 successful
downloads of alpha-2.  Is SourceForge going south on us (again)?

Re: [Jython-dev] Re: [Bug #126327] Infinite recursion in subpackage import

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

I will check this as soon as possible,

today or tomorrow.

If your solution is right I will just check it in.

regards, Samuele.

[Jython-dev] Re: [Bug #126327] Infinite recursion in subpackage import

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

>Bug #126327, was updated on 2000-Dec-19 05:28
>Here is a current snapshot of the bug.

>Summary: Infinite recursion in subpackage import

>http://sourceforge.net/bugs/?func=detailbug&bug_id=126327&group_id=12867

Here a possible patch. Since the CVS notification is out, and I'm unsure
whether this is right solution, I post it here. Basicly the patch checks
the sys.module for each level when walking down a dotted path.


--- imp.java.org	Mon Dec 18 20:18:43 2000
+++ imp.java	Tue Dec 19 13:57:52 2000
@@ -400,6 +400,8 @@
     private static PyObject dottedFind(PyObject mod, String name) {
       int dot = 0;
       int last_dot= 0;
+      PyObject modules = Py.getSystemState().modules;             
+
       do {
         String tmpName;
         dot = name.indexOf('.', last_dot);
@@ -408,9 +410,19 @@
         } else {
           tmpName = name.substring(last_dot, dot).intern();
         }
-        mod = mod.__findattr__(tmpName);
-        if (mod == null)
-          throw Py.ImportError("No module named " + tmpName);
+        PyObject m = null;
+        PyObject modname = mod.__findattr__("__name__");
+        if (name != null) {
+             String fullname = modname + "." + tmpName;
+             m = modules.__finditem__(fullname.intern());
+        }
+        if (m != null && m != Py.None) {
+             mod = m;
+        } else {
+             mod = mod.__findattr__(tmpName);
+             if (mod == null)
+                 throw Py.ImportError("No module named " + tmpName);
+        }
         last_dot = dot + 1;
       } while (dot != -1);
       return mod;

Re: [Jython-dev] Would like to see "threading" module built for jython

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

[Peter.Rupp]

>I like cpython's threading interface a lot...would like to see if you 
>can build it in jython?  Please? <grin>
>I'm using Java's wierd-but-works threading variety...YUK!

I have only done a quick test with the threading._test() method, but is
looks like some of the threading module works with jython.

Have you tried to copy the module from CPython2.0? You will also need
the atexit.py, even though it is mostly a no-op.

Let us know if the threading from cpython works for you. I will then
include it in the installer.

regards,
finn

[Jython-dev] Would like to see "threading" module built for jython

[<Pet...@ua...>]

All'

I like cpython's threading interface a lot...would like to see if you 
can build it in jython?  Please? <grin>
I'm using Java's wierd-but-works threading variety...YUK!

Best regards,
==pete==
P. A. Rupp 
United Airlines Corp. (WHQKT)
voice: 847-700-3226
email: pet...@ua...

Re: [Jython-dev] Second alpha release of Jython-2.0

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

I wrote:

>Jython-2.0a2 is now available. 

And the CVS is tagged and ready for new commits.

regards,
finn

[Jython-dev] Second alpha release of Jython-2.0

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

Jython-2.0a2 is now available. 

  http://jython.sourceforge.net/index.html

Install as with Jython-2.0a1. I don't intend to announce this any 
more widely than these lists for now.

The release includes some bug fixes as well as a few but crucial 
new features.

  New features:
    - Added -v (verbose) option to jython command. It will trace
      import statements. Use three -v's for maximum information.
    - A redesigned of the internal java class handling. The new
      design allow for a pluggable javaclass -> PyJavaClass handling.
      Included are plugins that use weak or soft references.
    - Use a SecureClassLoader for loading compiled python modules.
      This should allow jython to be used with the java plugin and
      its fine grained security.

  CPython-2.0 compatibility
    - Added support for formatting of long values in "%d %x %X %o".
      The support does not match CPython2.0 exactly, but matches
      what CPython2.1 will do.
    - The \x escape will only eat two hex characters and will 
      always create a character with values < 256. Use the \u
      escape for high-byte values.
    - A ucnhash module to support the \N{name} escape.


Take a look at the NEWS file for more information about the differences.

  http://jython.sourceforge.net/NEWS.html

Bugs can be reported to the bug manager on SourceForge:

  http://sourceforge.net/bugs/?group_id=12867

Cheers,
the jython-developers

[Jython-dev] [Patch #102778] PyJavaClass.classes mapping

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

Patch #102778 has been updated. 

Project: jython
Category: None
Status: Closed
Submitted by: bckfnn
Assigned to : pedronis
Summary: PyJavaClass.classes mapping

Follow-Ups:

Date: 2000-Dec-16 09:09
By: pedronis

Comment:
Absorbed by new internal tables design.
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102778&group_id=12867

RE: [Jython-dev] Question about old python.proxy.savedir

[Humbel O. <Otm...@bi...>]

[Finn]

> The proxy cache recently discussed here is the in-memory mapping from
> class names to the PyJavaClass which represent the class. Calling it a
> cache is probably wrong, the PyJavaClass.classes hashtable is 
> not about
> performance, but about ensuring a 1-1 mapping between a class and its
> PyJavaClass. The problem we have been talking about is how to ensure
> this 1-1 mapping when the java class haven't been loaded yet (what we
> call "lazy loading") and when the java class gets reloaded (different
> class with the same name).

Many thanks for the explanation.
 
> The proxy.savedir option were OTOH a true performance cache with the
> name of the java class as cache-key. The option was never enabled for
> JPython-1.1. There were several reasons for this omission:
> 
> - The proxies classes does not have a uniquely identifiable name
>   anymore. The generated proxy class name include a serial number
>   that makes it difficult to use a cache like the one in 1.0.3.
> - JPython-1.1 included new and much improved ways of freezing. If
>   the dynamic proxy creation is too slow, jpythonc can create the
>   proxies for you in advance.
> - Having a performance cache without any means of flushing the cache
>   when it gets stale is bad design. We still have no way of detecting
>   when a java have changed.

jythonc creating the proxies in advance would solve 95% of our problems, I
believe. 
I completely agree with you about the 'bad design': the handling is
horrible.
 
> We always need better performance. I have been thinking a little about a
> design where the generated proxies is stored at the end of the $py.class
> file. This would still not solve the flushing issue, but it would make a
> manual flush of the cached proxy much easier.

This also sounds interesting. We'll give Jython a try soon !

Thanks again and best wishes,
Oti.

Re: [Jython-dev] Keywords: embedding, securty

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

On Mon, 11 Dec 2000 10:34:30 +0000, you wrote:

>Hi,
>I have an application using JPython as its script interpreter. One of
>the
>end-users thinks he has found a security hole. If he puts
>python.security.respectJavaAccessibilty=false in the registry, the
>python
>script would be able to change private fields of the embedding classes.
>This surely cannot be true, can it?

Yes it is true and it is a feature.

If you want to disable the feature, you can explicit set the registry
entry during initialization in your application. Below I use the
Date.fastTime private field as an example:

import java.util.*;
import org.python.core.*;
import org.python.util.*;

public class si {
    public static void main(String[] args) {
        Properties props = new Properties();
        props.setProperty("python.security.respectJavaAccessibility",
                           "true");

        PySystemState.initialize(System.getProperties(), props, 
                                 new String[] {""});
        PythonInterpreter interp = new PythonInterpreter();

        interp.exec("import java");
        interp.exec("d = java.util.Date()");
        interp.exec("print d.fastTime");
    }
}

regards,
finn

[Jython-dev] [Patch #102778] PyJavaClass.classes mapping

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

Patch #102778 has been updated. 

Project: jython
Category: None
Status: Open
Submitted by: bckfnn
Assigned to : nobody
Summary: PyJavaClass.classes mapping

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102778&group_id=12867

[Jython-dev] Keywords: embedding, securty

[Arnold W. <awe...@ep...>]

Hi,
I have an application using JPython as its script interpreter. One of
the
end-users thinks he has found a security hole. If he puts
python.security.respectJavaAccessibilty=false in the registry, the
python
script would be able to change private fields of the embedding classes.
This surely cannot be true, can it?
TIA
Arnoud

Re: [Jython-dev] autoloading site.py

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

[Robert W. Bill]

>I just added a FAQ entry and had second thoughts about it's
>accuracy...

It's accurate.

>The registry key python.path appends the value *before* it appends
>sys.prefix/lib.  While appending to sys.path in autoloaded site.py happens
>*after* sys.prefix/lib.
>
>Q1- This is intended behavior? (I assumed so, just checking because there
>isn't an obvious counterpart in CPython.  Both *.pth and site.py append
>after sys.prefix/lib.)

It's how it works right now. I wouldn't mind changing it so python.path
as appended after sys.prefix/Lib. For my own development version of
python.path I also need the CPython libs after sys.prefix/lib, so I had
to add:

  python.path = .;i:\\java\\jython.CVS\\lib;d:\\python20\\lib

There is too much room for errors with this.

>Q2- Is the python.path key obsolete in the registry?  The lib does come
>with Jython, and site.py is autoloaded- what more could people want?  

python.path is still needed. I want a useful sys.path even when running
with the -S option (skip site import). I also want the ability to have a
replacement for sys.prefix/Lib inserted before the standard Lib.

My suggestion:

python.path is appended to sys.path after sys.prefix/Lib. Adding library
directories (including CPython's Lib) is usually done with python.path.

A new python.prepath option gets inserted before sys.prefix/Lib. Only
for use in very special cases. 

>Note: a search:replace with JPython:Jython on the registry file would be
>good- attached in case it saves any work (from 20001205 nightly CVS).

Thanks.

regards,
finn

Re: [Jython-dev] Question about old python.proxy.savedir

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

[Humbel Otmar]

>first many thanks for moving Jython on!
>
>I admit I was'nt fully able to follow (mean: understand) the latest
>discussion on proxies and cache design, so please forgive me if the
>questions below sound too naive.
>
>How is the relation of the new cache/proxy design to the old JPython 1.0.3.
>style proxy savedir ?
>	[snippet from good old registry file:]
>		#Only enable this if you're SURE you want it
>		python.proxy.savedir = n:/java/lib

The proxy cache recently discussed here is the in-memory mapping from
class names to the PyJavaClass which represent the class. Calling it a
cache is probably wrong, the PyJavaClass.classes hashtable is not about
performance, but about ensuring a 1-1 mapping between a class and its
PyJavaClass. The problem we have been talking about is how to ensure
this 1-1 mapping when the java class haven't been loaded yet (what we
call "lazy loading") and when the java class gets reloaded (different
class with the same name).

The proxy.savedir option were OTOH a true performance cache with the
name of the java class as cache-key. The option was never enabled for
JPython-1.1. There were several reasons for this omission:

- The proxies classes does not have a uniquely identifiable name
  anymore. The generated proxy class name include a serial number
  that makes it difficult to use a cache like the one in 1.0.3.
- JPython-1.1 included new and much improved ways of freezing. If
  the dynamic proxy creation is too slow, jpythonc can create the
  proxies for you in advance.
- Having a performance cache without any means of flushing the cache
  when it gets stale is bad design. We still have no way of detecting
  when a java have changed.

>Do we still need these proxies with Jython 2.0 ? We definitely need them in
>JPython 1.0.3 and we almost rebuilt them again for JPython 1.1 - for runtime
>performance reasons.

We always need better performance. I have been thinking a little about a
design where the generated proxies is stored at the end of the $py.class
file. This would still not solve the flushing issue, but it would make a
manual flush of the cached proxy much easier.

regards,
finn

[Jython-dev] Question about old python.proxy.savedir

[Humbel O. <Otm...@bi...>]

Hello Jython developers,

first many thanks for moving Jython on!

I admit I was'nt fully able to follow (mean: understand) the latest
discussion on proxies and cache design, so please forgive me if the
questions below sound too naive.

How is the relation of the new cache/proxy design to the old JPython 1.0.3.
style proxy savedir ?
	[snippet from good old registry file:]
		#Only enable this if you're SURE you want it
		python.proxy.savedir = n:/java/lib

Do we still need these proxies with Jython 2.0 ? We definitely need them in
JPython 1.0.3 and we almost rebuilt them again for JPython 1.1 - for runtime
performance reasons.


Thank you for your comments,
Oti