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

Re: [Jython-dev] copyright characters in source files

[Bill K. <bi...@ct...>]

From: "Ben Burton" <be...@ac...>
> 
[...]
> So basically what I'm going to ask is for all the copyright characters to be 
> replaced with (c). :)  I realise this is an onerous task (although one that 
> only took me a few minutes with a for loop in bash and a lot of repetitive 
> keystrokes in vi).

Hi, I'm still a Python newbie (so don't know of an optimal Python
solution for this yet) but Perl is phenomenal for this sorta thing:

find somedir -type f -name "*.java" | perl -i -npe 's/\123/(c)/g'

where \123 could be the octal representation of the highbit char
to be replaced with (c).

(Note: under Windows the -i would have to be changed to something
like -i.bak because win perl can't edit files in-place.)

Hope this helps,

Bill

[Jython-dev] copyright characters in source files

[Ben B. <be...@ac...>]

Hi.. a note on a different subject.

I'm using jikes to build jython.  Some time ago I got an error regarding the 
use of the copyright character in a quoted string (in sha.java).  Which was 
fine, I just edited the file and replaced the character with (c) and all was 
well.

Now, since my last upgrade, jikes gets upset when the file contains 
non-standard characters.  Even in comments.

So suddenly I find myself having to manually edit some 114 files to replace 
copyright characters with (c) in the comment headers, eg.:
// Copyright (c) Corporation for National Research Initiatives

The error jikes gives me is:

jikes +E +D -g -classpath 
"../../..:/usr/share/java/libgcj.jar:/usr/share/kaffe/rmi.jar:/usr/share/java/servlet-2.2.jar" 
ArgListCompiler.java
Charset conversion error at offset 13: Invalid or incomplete multibyte or 
wide character

You could say "just don't use jikes", but jikes is explicitly designed to 
adhere precisely to language and VM specifications; no more, no less.  So I 
would claim we *want* jython to compile with jikes because this should mean 
it will compile with any sane and compliant java compiler.

So basically what I'm going to ask is for all the copyright characters to be 
replaced with (c). :)  I realise this is an onerous task (although one that 
only took me a few minutes with a for loop in bash and a lot of repetitive 
keystrokes in vi).

If people don't have the time to do it, I will happily do this myself if 
you're willing (I have a sourceforge account, username bab).

Thanks,
	Ben.

-- 

Ben Burton
be...@ac...  |  ba...@de...
http://baasil.humbug.org.au/bab/
Public Key: finger ba...@de...

Art is the most intense mode of individualism that the world has known.
	- Oscar Wilde

[Jython-dev] jython, readline and GPL (again)

[Ben B. <be...@ac...>]

Hi.. just for reference, a followup to the July 1 thread on GPL-compatibility 
issues with readline support if anyone's interested.

I've patched Bernhard Bablok's readline wrappers to link with libedit.so 
instead of libreadline.so.  The libedit library has a BSD-style license and 
so it becomes completely irrelevant whether or not the FSF thinks jython is 
GPL-compatible.

The libedit library is included in debian unstable and should be in the 
forthcoming woody release; I'm not sure about other linux distributions.  The 
version in debian seems to be a CVS snapshot:

------
It was checked out from NetBSD CVS on 2001-08-21.
(CVSROOT :pserver:an...@an...:/pub/NetBSD-CVS)
 
Upstream Author: NetBSD Foundation
------

So what I've done with the debian packaging is upload lib-editline-java which 
has the same API as Bernhard's wrappers except for a couple of functions 
which are missing (that don't affect jython) and I'm now preparing jython so 
it builds and runs against lib-editline-java instead of lib-readline-java.  
I've already tested it and the editline support seems to work fine.

Anyway, I realise this might not affect a great deal of people and I realise 
that some people don't give a flying fruitcake what the FSF thinks about 
jython's GPL-compatibility.  But some distributors need to cover their 
proverbial arses (such as debian, which is large and volunteer) and make sure 
that everything is unquestionably legal, and so this is basically a note to 
tell you all that it's possible.

I've already sent the editline patches to Bernhard; if anyone's interested, I 
can mail them out.  Plot summary is that readInitFile() and parseAndBind() 
had to be commented out (not supported in libedit) and the rest was pretty 
much makefile changes.  Alternatively, you can wait a couple of days for 
lib-editline-java to get through the debian incoming queue and then find the 
packages (including sources and patches) at 
http://packages.debian.org/lib-editline-java .

Ben.

-- 

Ben Burton
be...@ac...  |  ba...@de...
http://baasil.humbug.org.au/bab/
Public Key: finger ba...@de...

A little sincerity is a dangerous thing, and a great deal of it is
absolutely fatal.
	- Oscar Wilde

Re: [Jython-dev] jython java access

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

Kevin,

>How does this relate to Python's restricted execution mode?
>
>It seems there would be substantial overlap, but I haven't ever tried using rexec in Jython...
>
>http://py-howto.sourceforge.net/rexec/rexec.html

Unfortunately, the rexec module is not available in jython.

Ype.


>kb
>
>Chr...@ge... wrote:
>>
>> Hi Folks,
>>
>> we are currently trying to use Jython to give users the possibility to
>> enter python scripts to automate some steps in a Java application we are
>> developing. We want to provide the users an API with Java Classes. But we
>> want to restrict the user that he can only use these public Classes from
>> the API. For this we first set Options.respectJavaAccessibility to true. To
>> be able to restrict the user to the API the introduced a new interface
>> JavaAccessInterceptor and made some small changes to class PyJavaClass.
>> Mainly a new method setJavaAccessInterceptor(JavaAccessInterceptor
>> anInterceptor) to set an interceptor and a call of the interceptor in the
>> methods getAccessibleConstructors, getAccessibleFields and
>> getAccessibleMethods.
>>
>> I did this changes in the python version 2.0. but I think it is also
>> possible in the version 2.1a3.
>>
>> We think the change can be useful for other jython users and would like if
>> you are able to ingrate the changes or provide something similar.
>> What do you think about this ?
>>
>> Probably it would be better to call the interceptor also in the case when
>> Options.respectJavaAccessibility is set to false.....
>>
>> Regards
>>      Christian.
>>
>> (See attached file: src.jar)
>>
> >                                                  

Re: [Jython-dev] jython java access

[Kevin B. <kb...@ca...>]

How does this relate to Python's restricted execution mode?

It seems there would be substantial overlap, but I haven't ever tried using rexec in Jython...

http://py-howto.sourceforge.net/rexec/rexec.html

kb

Chr...@ge... wrote:
> 
> Hi Folks,
> 
> we are currently trying to use Jython to give users the possibility to
> enter python scripts to automate some steps in a Java application we are
> developing. We want to provide the users an API with Java Classes. But we
> want to restrict the user that he can only use these public Classes from
> the API. For this we first set Options.respectJavaAccessibility to true. To
> be able to restrict the user to the API the introduced a new interface
> JavaAccessInterceptor and made some small changes to class PyJavaClass.
> Mainly a new method setJavaAccessInterceptor(JavaAccessInterceptor
> anInterceptor) to set an interceptor and a call of the interceptor in the
> methods getAccessibleConstructors, getAccessibleFields and
> getAccessibleMethods.
> 
> I did this changes in the python version 2.0. but I think it is also
> possible in the version 2.1a3.
> 
> We think the change can be useful for other jython users and would like if
> you are able to ingrate the changes or provide something similar.
> What do you think about this ?
> 
> Probably it would be better to call the interceptor also in the case when
> Options.respectJavaAccessibility is set to false.....
> 
> Regards
>      Christian.
> 
> (See attached file: src.jar)
> 
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                  Name: src.jar
>    src.jar       Type: application/zip
>              Encoding: base64
>           Description: .ZIP File

RE: [Jython-dev] Float and imag literals

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

[Finn Bock]
> No. Jython can handle some of these already:

Great!  Think of this as CPython following Jython's lead, then <wink>.

> ...
> The failing one is as easy to fix as it should be, when you have a
> general purpose lexer at your disposal.

Ya, I figured it would be.  It wasn't hard in CPython either, where we enjoy
the magical power of mountains of gotos <snort>.

more-than-one-way-to-lex-a-token-ly y'rs  - tim

[Jython-dev] jython java access

[<Chr...@ge...>]

Hi Folks,

we are currently trying to use Jython to give users the possibility to
enter python scripts to automate some steps in a Java application we are
developing. We want to provide the users an API with Java Classes. But we
want to restrict the user that he can only use these public Classes from
the API. For this we first set Options.respectJavaAccessibility to true. To
be able to restrict the user to the API the introduced a new interface
JavaAccessInterceptor and made some small changes to class PyJavaClass.
Mainly a new method setJavaAccessInterceptor(JavaAccessInterceptor
anInterceptor) to set an interceptor and a call of the interceptor in the
methods getAccessibleConstructors, getAccessibleFields and
getAccessibleMethods.

I did this changes in the python version 2.0. but I think it is also
possible in the version 2.1a3.

We think the change can be useful for other jython users and would like if
you are able to ingrate the changes or provide something similar.
What do you think about this ?

Probably it would be better to call the interceptor also in the case when
Options.respectJavaAccessibility is set to false.....

Regards
     Christian.

(See attached file: src.jar)

Re: [Jython-dev] Float and imag literals

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

[Tim Peters]

>Hi -- I'm about to check in a change to Python's float literal syntax:
>
>http://sf.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470
>
>Currently, CPython doesn't allow a float or imag literal to begin with a
>string of digits that "looks like" an octal literal, except for the specific
>prefix "0.".  Things like
>
>   00.0
>   0e3
>   0100j
>   09.5
>
>are all rejected as SyntaxErrors.  After the patch, those are all accepted.
>
>Will this create problems for Jython?

No. Jython can handle some of these already:

Jython 2.1a3 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> 00.0
0.0
>>> 0e3
0.0
>>> 0100j
Traceback (innermost last):
  (no code object) at line 0
  File "<console>", line 1
        0100j
            ^
SyntaxError: invalid syntax
>>> 09.5
9.5
>>>

The failing one is as easy to fix as it should be, when you have a
general purpose lexer at your disposal.

regards,
finn

[Jython-dev] [ jython-Patches-456993 ] PyFile truncate()

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Randy Jay Yarger (ryarger)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyFile truncate()

Initial Comment:
Jython does not support truncate() (as does CPython)
even though some types of files (such as
RandomAccessFiles) have this ability in Java.

Attached is a patch to add truncate()


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

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

[Jython-dev] Float and imag literals

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

Hi -- I'm about to check in a change to Python's float literal syntax:

http://sf.net/tracker/?func=detail&atid=305470&aid=455966&group_id=5470

Currently, CPython doesn't allow a float or imag literal to begin with a
string of digits that "looks like" an octal literal, except for the specific
prefix "0.".  Things like

   00.0
   0e3
   0100j
   09.5

are all rejected as SyntaxErrors.  After the patch, those are all accepted.

Will this create problems for Jython?  It required looking ahead in Python's
by-hand lexer (e.g.,

    090000000000000.

is a legit float literal after the patch, but take off the trailing point
and it's still a SyntaxError (an octal literal with the digit '9').

significant-leading-zeroes-are-insane-ly y'rs  - tim

Re: [Jython-dev] Exception Handling difference between CPython and Jython

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

[Kevin Dangoor]

>We took a quick glance at CPython yesterday, and it didn't look like it was
>doing anything special to handle this. 

I guess it happens here in CPython:

> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/classobject.c?annotate=2.143#1559

>The exception basically seemed to
>just disappear. It would be a simple patch to just make the __nonzero__
>function toss out any exception that occurs when searching the Python
>classes for __nonzero__. But is that the "right" way?

I think it is. Normally it is very bad to silently ignore exceptions,
but since __nonzero__ already have __len__ as fallback, it may be the
right think to do here.

In any case, please submit a bug report about it to the SF bug tracker.

regards,
finn

Re: [Jython-dev] Exception Handling difference between CPython and Jython

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

We took a quick glance at CPython yesterday, and it didn't look like it was
doing anything special to handle this. The exception basically seemed to
just disappear. It would be a simple patch to just make the __nonzero__
function toss out any exception that occurs when searching the Python
classes for __nonzero__. But is that the "right" way?

Kevin

----- Original Message -----
From: "Randy Jay Yarger" <ry...@we...>
To: <jyt...@li...>
Sent: Wednesday, August 29, 2001 4:42 PM
Subject: [Jython-dev] Exception Handling difference between CPython and
Jython


> Howdy,
>
> There appears to be a slight difference in the exception handling
> between CPython and Jython.
> Before I dig into CPython's code I want to see if this is a known problem.
>
> Here is my test case:
> -----------------------------------
> class Foo:
>     def __getattr__(self, key):
>         print 'getting %s' % key
>         raise KeyError, key
>
> foo = Foo()
> if not foo: print 'no foo'
> -------------------------------------
>
> CPython has the following output:
> =========================
> getting __nonzero__
> getting __len__
> =========================
>
> Where Jython does this:
> =========================
> WE: getting __nonzero__
> Traceback (innermost last):
>   File "tc.py", line 7, in ?
>   File "tc.py", line 4, in __getattr__
> KeyError: __nonzero__
> ==========================
>
> Since _getattr__ always raises an error, it seems the CPython is doing
> something magical under the hood.
>
> Has anyone seen anything similar?
>
> Thanks,
> Randy Jay Yarger (ry...@we...)
> Phabric Development (www.phabric.org) @ Web Elite (www.webelite.com)
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] Exception Handling difference between CPython and Jython

[Randy J. Y. <ry...@we...>]

Howdy,

There appears to be a slight difference in the exception handling 
between CPython and Jython.
Before I dig into CPython's code I want to see if this is a known problem.

Here is my test case:
-----------------------------------
class Foo:
    def __getattr__(self, key):
        print 'getting %s' % key
        raise KeyError, key

foo = Foo()
if not foo: print 'no foo'
-------------------------------------

CPython has the following output:
=========================
getting __nonzero__
getting __len__
=========================

Where Jython does this:
=========================
WE: getting __nonzero__
Traceback (innermost last):
  File "tc.py", line 7, in ?
  File "tc.py", line 4, in __getattr__
KeyError: __nonzero__
==========================

Since _getattr__ always raises an error, it seems the CPython is doing 
something magical under the hood.

Has anyone seen anything similar?

Thanks,
Randy Jay Yarger (ry...@we...)
Phabric Development (www.phabric.org) @ Web Elite (www.webelite.com)

[Jython-dev] **LOW COST SOFTWARE DEVELOPMENT**

[BrainCoders.com <mai...@br...>]

Dear Internet User,

The eBusiness is changing the software applications and 
services landcape in a way that has not been seen 
earlier. Companies worldwide are waking up to the fact 
that the difference between just having an Online 
Presence and using the web as a strategic medium can mean 
all the difference to success. 

What this also means is that you need technology 
providers who understand the business implications of 
technology and can make sure that the solutions work with 
your exisiting business processes as also enable you to 
integrate new processes without massive investments in 
changing the whole Application Architecture. 

BrainCoders.com is a software company dedicated to 
designing and developing the highest-quality software to 
provide our clients with workable, maintainable and 
leading-edge solutions. We are specializing in IT 
services and software outsourcing. 

Our prices are one of the lowest on the market. We charge 
our customers from $8 to $15 per working hour depending 
on the length and complexity of the project.

Our leading principle is to consistently deliver on time 
and on budget. 
Our most value asset is our team of most committed and 
capable people. 

This dedication to high degrees of professionalism 
translates to innovative and cost effective solutions. 
The bottom line is that we help our clients gain 
competitive advantage and maintain their leading 
positions in their respective industries.

BrainCoders.com' software development services may be of 
special interest to the following groups of potential 
customers: 

Software houses that wish to reduce their development 
costs by means of outsourcing.

Companies not directly involved in software development, 
but which have or need their proprietary software 
business applications and wish to delegate the 
development, upgrades and support of these applications 
to a software company.

For more information please visit our web site by 
clicking the following link:

http://www.braincoders.com

If you are interested in our services, I would be happy 
to provide you with any information you may request.

I am looking forward to hearing from you.

BestRegards,

Vesselin Sladkov
BrainCoders.com
E-mail: sl...@br...

_________________________________________________________
This mailing is done only to people who have requested 
info from one of our sites, or downloaded
our Software. If you have recieved this email in error 
and you wish to be removed from future 
mailings, please reply with the subject "Remove" and our 
software will automatically block you 
from their future mailings.
_________________________________________________________

[Jython-dev] Jython Support in IBM VisualAge for Java

[Rick S. <rs...@pa...>]

Greetings,

I seem to remember a post in an IBM newsgroup by Bradley Schatz
that detailed mods to PackageManager in JPython to allow it to work
within as well as outside IBM VAJava. However, I cannot find the
document in USENET any longer...only the 1st part of the message
without the actual code.

Does anyone in your group have access to this document? Has anyone
updated it (if necessary) to work with Jython and VAJava?

Thanks for any info,

Rick Strong
rs...@pa...

[Jython-dev] dinamic classloader and add_classdir

[Davide M. <da...@ds...>]

Hi, I want call a jython script within a servlet.
But I want that the classes used in the python
script are accessible throught a classloader other
than the system classloader.

I construct the classloader appropriately, then
I make 

         PySystemState jpState = new PySystemState();
         jpState.setClassLoader(_urlcl);
         jpState.initialize();

then i whould like that the classes are accessible with:

         PySystemState.add_classdir(_path);
         
where _path contains the dir where the classloader point to.
Then

   
       PythonInterpreter interp = new PythonInterpreter(null, jpState);


But during the execution, an exception fires. It say
that the module can't be found.

Is the way right? Note that the python classes are loaded
with the system class loader.

Any suggestion. Very thanks. Jython is very good.

Bye.

Davide.

[Jython-dev] Classloader and add_classdir

[Davide M. <da...@ds...>]

Hi, I want call a jython script within a servlet.
But I want that the classes used in the python
script are accessible throught a classloader other
than the sistem classloader.

I construct the classloader appropriately, then
I make 


         PySystemState.initialize();
         for (int i = 0; i < _paths.length; i++)
         {
            System.out.println("Aggiungo il seguente path per trovare le
classi: " + _paths[i]);
            PySystemState.add_classdir(_paths[i]);
         }
         jpState.initialize();
            //org.python.core.PySystemState.

         //jpState.initialize();
         PythonInterpreter interp = new PythonInterpreter(null,
jpState);

Re: [Jython-dev] nightmare: PEP 252, PEP 253 and jython issues

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

Hi. I agree with your considerations, in the discussion with Guido
I was trying to understand how serious he was about the new mro
at C level and with the very basic types.
It seems that the semantics of Python will have a bit more holes
and that Guido's philosophy is: there are some rules for the rest
let it be ... so we have some space to take *our*
decisions.

>
> [SP]
> >A natural way to design PEP252, and PEP253 for Jython would
> >be start to start from the equation:
> >
> >object = org.python.core.PyObject
>
> Conceptional I agree, but do you also think that a simple
>
>    class A(object): pass
>
> should create a true subclass of PyObject? That would add the proxy
> overhead to all python classes, wouldn't it?
No, in any case java subclassing from Jython as it is, would not do the trick.
The point is more that if someone subclasses PyObject in Java we should treat
that as a type and not as a simple JavaClass. I think it is important to
support
 that at least.

What class A(object): pass should do is still unclear to me.  To be honest
we can have probably a lot of freedom about what that produces but
the point is what then A() should deliver.
The other main  points are:
type = ?
object = ?
both at Jython and internal level.

Another problem is that we should decide how the whole new type stuff
should interact with Jython level Java subclassing.

>
> [SP]
> > ..., I'm worried about this scenario
> >
> > A subclasses object and redefines __getattr__
> > B subclasses list
> >
> > then class C(B,A): ...
> >
> > will have the following mro:
> >
> > C B list A object
> >
> > [snip]
> >
> > now A is in between list and object: what is the right thing here?
>
> That was a very good catch (bravo), but we should ignore the problem for
> the builtin types like list and dictionary. A flexible mro like this
> that depends on an inheritance graph defined later (maybe in another
> module) should not be followed by our builtin types.
>
> After all, "B isa list isa object". There is no A in that static linage,
> no matter what GvR think python2.2 should do.
Yes, it seems  that for Guido we can use simple direct Java
subclassing for Java level Jython types, but if that doesn't
work well, we cannot call him guilty <wink>.

> The restrictions that GvR put in place when subclassing dictionary make
> subclassing of types highly overrated. It doesn't seem to have much
> practical purpose.
Yup, but at the C (our Java) level his philosophy is more: no restrictions
and is up to the programmer to play safe.

>
> > In Jython codebase hypothetically but possibly list could contains
> > calls like:
> >
> >   __getattr__(...)
> >   and super.__getattr__
>
> Which should 100% be resolved as normal java virtual method calls.
>
> The effect of any such decission that we make, may mean that jython
> types are a little less flexible than their CPython counterpart. I can
> live with that.
My impression has been that at least the built-in will remain
inflexible also on CPython side, that Guido has no intention
to specify how that much flexibility should be used, so I presume
things pratically will remain inflexible or ... caothic.

>
> [SP] *bad-guy-java*
> > Yes ... very slow and we would have to use that also at the very
> > core of the hierarchy, see (*) but the problem is more
> > complicated, in Java given three classes
> >
> > C extends B extends A
> > and a method m
> > C.m overrides B.m overrides A.m
> >
> > there is not direct way (even using reflection)
> > to apply B.m behaviour to a C object, unless
> > the programmer has left some hook in C using super
> > or in B ( a method B_m e.g.).
>
> Is this more of a problem in 2.2 than it is now? OTOH I can see the
> problems if all python classes subclass PyObject, but I can't see that
> as a way forward.
mmh, no PyObject and the built-in types are not that big problem, we
can special case and are under our control and their hierarchies are
shallow, the problem is more if someone creates a deep hierarchy
of types (PyObject subclasses) in Java:

C isa B isa A isa PyObject

because in principle if they all override __getattr__ the descr semantic
says that we should extract the behaviour at all levels.

There are many issues, but the major problem is not that we can't find
solutions but that no good solution would probably be a quick hack.

regards, Samuele Pedroni.

[Jython-dev] nightmare: PEP 252, PEP 253 and jython issues

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

[responding to a thread on python-dev regarding the type/class
unification in PEP252 and PEP253. I'm writing it here because I need a
little time to get my head around the issues]

[SP]
>A natural way to design PEP252, and PEP253 for Jython would
>be start to start from the equation:
>
>object = org.python.core.PyObject

Conceptional I agree, but do you also think that a simple

   class A(object): pass

should create a true subclass of PyObject? That would add the proxy
overhead to all python classes, wouldn't it?

I have a feeling that we should treat object specially when used as a
superclass. Similar should calls to default behaviour in object be
treated as a special situation.

[SP]
> ..., I'm worried about this scenario
> 
> A subclasses object and redefines __getattr__
> B subclasses list
> 
> then class C(B,A): ...
> 
> will have the following mro:
> 
> C B list A object
> 
> [snip]
>
> now A is in between list and object: what is the right thing here?

That was a very good catch (bravo), but we should ignore the problem for
the builtin types like list and dictionary. A flexible mro like this
that depends on an inheritance graph defined later (maybe in another
module) should not be followed by our builtin types.

After all, "B isa list isa object". There is no A in that static linage,
no matter what GvR think python2.2 should do.

The restrictions that GvR put in place when subclassing dictionary make
subclassing of types highly overrated. It doesn't seem to have much
practical purpose.

> In Jython codebase hypothetically but possibly list could contains
> calls like:
> 
>   __getattr__(...)
>   and super.__getattr__

Which should 100% be resolved as normal java virtual method calls. 

The effect of any such decission that we make, may mean that jython
types are a little less flexible than their CPython counterpart. I can
live with that. 

[SP] *bad-guy-java*
> Yes ... very slow and we would have to use that also at the very
> core of the hierarchy, see (*) but the problem is more
> complicated, in Java given three classes
> 
> C extends B extends A
> and a method m
> C.m overrides B.m overrides A.m
> 
> there is not direct way (even using reflection) 
> to apply B.m behaviour to a C object, unless
> the programmer has left some hook in C using super
> or in B ( a method B_m e.g.).

Is this more of a problem in 2.2 than it is now? OTOH I can see the
problems if all python classes subclass PyObject, but I can't see that
as a way forward.

regards,
finn

Re: [Jython-dev] Kaffe

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

[Mats Wichmann]

>I bet the rest of us can scare up some cycles between us to do
>some testing against other JVMs (you and Finn do so much already!),
>and supply info on the results.

That would be very good.

>On the other hand, what's the general impression on whether
>this is important?

Its important for jython. When jython can run on less common platforms
it gives the impression that jython is easy to incorporate in other
software.

>I just saw some note on IBM's JVM here,
>and Ben's done some work on Kaffe, apparently.  I'd be willing
>to do a bit of testing there, too.  But then what? What if
>problems are discovered?  Do we just add notes on them saying
>"XXX does not appear to work" (period-end-of-story)?

Then you fix the problem by comming up with patches and workarounds
<wink>.

It is general problem with ports. Somebody have to do the work of
testing and analysing the problems that occur. When nobody does, the
platform gets neglected.

What can we do to make it easier to test a JVM? We could add the Jython
and CPython test suites to the installer as an optional component. That
way a fairly good coverage can be achieved  by running two scripts.

At the moment you will have to install a CPython-211 and add a line to
your $HOME/.jython file:

   python.path=/path/to/Python211/Lib

and run the script below.

regards,
finn



import test.regrtest

tests = [
    'test___all__',
    'test___future__',
    'test_atexit',
    'test_augassign',
    'test_binascii',
    'test_binhex',
    'test_bisect',
    'test_bufio',
    'test_builtin',
    'test_cfgparser',
    'test_cgi',
    #'test_charmapcodec',
    #'test_class',
    'test_coercion',
    #'test_compare',
    'test_compile',
    'test_complex',
    'test_contains',
    #'test_cookie',
    'test_copy_reg',
    'test_cpickle',
#   'test_crypt',
    'test_difflib',
    #'test_doctest',
    'test_dospath',
    'test_dumbdbm',
    #'test_exceptions',
    #'test_extcall',
    'test_file',
    'test_fnmatch',
    'test_format',
    'test_funcattrs',
    'test_future',
    'test_getopt',
    'test_global',
    #'test_grammar',
    'test_gzip',
    'test_hash',
    'test_import',
    'test_long',
    'test_mailbox',
    'test_math',
    'test_md5',
    'test_mimetools',
    'test_MimeWriter',
    'test_new',
    'test_ntpath',
    'test_opcodes',
    #'test_operations',
    'test_operator',
    'test_pickle',
    'test_pkg',
    'test_posixpath',
    'test_pow',
    'test_re',
    'test_rfc822',
    'test_richcmp',
    #'test_scope',
    'test_sha',
    'test_socket',
    #'test_sre',
    'test_strftime',
    'test_string',
    'test_StringIO',
    'test_struct',
    'test_thread',
    'test_threadedtempfile',
    'test_time',
    'test_tokenize',
    'test_types',
    #'test_ucn',
    'test_unicode',
    'test_unpack',
    'test_urllib',
    'test_urlparse',
    'test_userdict',
    #'test_userlist',
    'test_userstring',
    #'test_weakref',
    'test_xmllib',
    #'test_xreadline',
    'test_zipfile',
    #'test_zlib',
]

test.regrtest.main(tests)

Re: [Jython-dev] Kaffe

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

At 06:02 PM 8/24/2001 +0200, Samuele Pedroni wrote:
 >
 >[Ben Burton]
 >>
 >> Just did a hunt and amongst other
 >> things the actual jython site says (http://www.jython.org/platform.html):
 >>
 >> Kaffe
 >>
 >> Jython does not work with the current version available from transvirtual.
 >> This appears to be both due to some small incompatibilities between this
 >> Java VM and SUN's version, as well as at least one serious issue which is
 >> the lack of a java.math.BigInteger class -- this lack will be a problem
 >> for any VM that only implements the PersonalJava subset of the full Java
 >> spec. It should be possible to get Jython working on this VM if someone
 >> has the time to invest, please let us know if you have any success here or
 >> need any help.
 >>
 >Ooops, but don't expect that to be up to date, I think it's even pre-Jython
 >stuff ... personally I don't have time to play with various VMs and think
 >Finn either, but if someone has new fresh info, then we can refresh the site.


I bet the rest of us can scare up some cycles between us to do
some testing against other JVMs (you and Finn do so much already!),
and supply info on the results.

On the other hand, what's the general impression on whether
this is important?  I just saw some note on IBM's JVM here,
and Ben's done some work on Kaffe, apparently.  I'd be willing
to do a bit of testing there, too.  But then what?  What if
problems are discovered?  Do we just add notes on them saying
"XXX does not appear to work" (period-end-of-story)?

Mats

Re: [Jython-dev] Kaffe

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

[Ben Burton]
>
> Just did a hunt and amongst other
> things the actual jython site says (http://www.jython.org/platform.html):
> 
> Kaffe
> 
> Jython does not work with the current version available from transvirtual.
> This appears to be both due to some small incompatibilities between this
> Java VM and SUN's version, as well as at least one serious issue which is
> the lack of a java.math.BigInteger class -- this lack will be a problem
> for any VM that only implements the PersonalJava subset of the full Java
> spec. It should be possible to get Jython working on this VM if someone
> has the time to invest, please let us know if you have any success here or
> need any help.
> 
Ooops, but don't expect that to be up to date, I think it's even pre-Jython
stuff ... personally I don't have time to play with various VMs and think
Finn either,
but if someone has new fresh info, then we can refresh the site.

regards, Samuele Pedroni.

Re: [Jython-dev] Kaffe

[Ben B. <bb...@ma...>]

> So just out of curiosity, how far is Kaffe from being
> usable, and what is it it doesn't provide?

Just did a hunt and amongst other
things the actual jython site says (http://www.jython.org/platform.html):

Kaffe

Jython does not work with the current version available from transvirtual.
This appears to be both due to some small incompatibilities between this
Java VM and SUN's version, as well as at least one serious issue which is
the lack of a java.math.BigInteger class -- this lack will be a problem
for any VM that only implements the PersonalJava subset of the full Java
spec. It should be possible to get Jython working on this VM if someone
has the time to invest, please let us know if you have any success here or
need any help.

Ben.

Re: [Jython-dev] Kaffe

[Ben B. <bb...@ma...>]

> So just out of curiosity, how far is Kaffe from being
> usable, and what is it it doesn't provide?

Hmm, I've done some *very* minimal testing with kaffe and jython and I
didn't run into any problems.  This was for precisely the reason you
mention - I can't put jython in the main debian distribution unless it
runs on a free JVM.

Cool, if anyone knows where kaffe is supposed to fail with jython I'll be
interested to see.

Ben.

[Jython-dev] Kaffe

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

At one point I read that Kaffe didn't have enough juice
to support Jython, so I never tried.  The Sun Java SDK
doesn't give me any problems, but it does require
that some code be downloaded that can't appear on a
Linux distribution CD due to the licensing, and this
could be troubling to some on "GNU Philosophy" grounds,
and troubling to others just because there's work to
be done if they put together a Jython app for distribution
on Linux.

So just out of curiosity, how far is Kaffe from being
usable, and what is it it doesn't provide?

Mats