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

Re: [Jython-dev] jythonc with xml.sax

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

-> have any of you successfully compiled a program that imports xml.sax ?
-> i couldn't get the xml module to be created even when I use --deep switch on
-> jythonc

Yes, I did.  It was no fun, though; I'm almost glad to hear that someone
else is having problems ;).

In the end, I had to do two things:

* unpack and repack xerces.jar (I'm using Xerces-J 1 from xml.apache.org);
* include sax2.jar

I do not understand why either of these things was necessary, since
things worked fine with the interpreter when I simply put xerces.jar
in jre/lib/ext.  *shrug*

The package is GPL, and you can get the dist Makefile & JARs from CVS
on Sourceforge.  Check out http://familjewels.sourceforge.net/.

cheers,
--titus

[Jython-dev] jythonc with xml.sax

[Gunadi, W. <Wiw...@co...>]

hi!
have any of you successfully compiled a program that imports xml.sax ?
i couldn't get the xml module to be created even when I use --deep switch on
jythonc

Wiwih "Will" Gunadi
CGF Developer
972.577.0332
wiw...@co...
Compuware Corp. - Products

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 09:11 PM 7/15/01 +0200, Samuele Pedroni wrote:
>I'm fine with your version, but I don't really see what was the problem with
>mine,
>maybe the posted stuff was not readable but code logic was:
>
>if (!(bases[i] instanceof PyClass)) {
>   // old logic
>} else /* so bases[i]  is/derives from PyClass */ if (bases[i] instanceof
>org.python.util.PyMetaClass) {
>   // meta-class logic
>}
>
>so the new code is triggered by subclasses of PyClass implementing PyMetaClass
>...

Oops.  You're right.  My brain read your version as "if (bases[i] 
instanceof PyClass)", which is not what you actually wrote.  Either version 
should work.  Mea culpa.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 11:29 AM 7/15/01 +0000, Finn Bock wrote:

>OTOH, if you can deliver an ExtensionClass compatible module, then it is
>an excellent argument in favor of keeping the proposed PyMetaClass hook.

If anyone is interested, the source for my primitive implementation of 
ExtensionClass.Base is now available at:

http://cvs.eby-sarna.com/Jython/JExtClass/

No documentation yet, and the __of__ protocol is not fully implemented; 
it's only in effect for items retrieved from the class, not from the 
instance dictionary or from a __getattr__, but it's a start.  I'll probably 
redo this later by redefining the ifind* methods instead of hijacking 
_doget(), which will then allow the use of MethodObjects for special 
methods like __len__, __getitem__, etc.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

Hi.

> Here's a version of your patch that works with my minimal ExtensionClass
> emulation:
>
[snip patch]
> It's the same as yours, except that it goes before the PyClass check, so
> that an object that "extends PyClass implements PyMetaClass" will be
> treated as a metaclass.
I'm fine with your version, but I don't really see what was the problem with
mine,
maybe the posted stuff was not readable but code logic was:

if (!(bases[i] instanceof PyClass)) {
  // old logic
} else /* so bases[i]  is/derives from PyClass */ if (bases[i] instanceof
org.python.util.PyMetaClass) {
  // meta-class logic
}

so the new code is triggered by subclasses of PyClass implementing PyMetaClass
...
I should be very tired ...

Samuele Pedroni.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 03:42 AM 7/15/01 +0200, Samuele Pedroni wrote:

>So after the trouble of  a few posts and of making me propose a bad and not
>working hack, you came out
>with some actual code <wink>.

I could've proposed code to start with, but as you can see, my Java isn't 
as good as my Python.  :)

Here's a version of your patch that works with my minimal ExtensionClass 
emulation:

? org/python/util/PyMetaClass.java
Index: org/python/core/Py.java
===================================================================
RCS file: /cvsroot/jython/jython/org/python/core/Py.java,v
retrieving revision 2.46
diff -u -r2.46 Py.java
--- org/python/core/Py.java     2001/07/03 20:20:27     2.46
+++ org/python/core/Py.java     2001/07/15 14:18:27
@@ -1406,6 +1406,10 @@
      }


+    private static Class[] pyClassCtrSignature =
+        {String.class,PyTuple.class,PyObject.class,Class.class};
+
+
      public static PyObject makeClass(String name, PyObject[] bases,
                                       PyCode code, PyObject doc,
                                       Class proxyClass,PyObject[] 
closure_cells)
@@ -1419,6 +1423,14 @@
              dict.__setitem__("__doc__", doc);

          for (int i=0; i<bases.length; i++) {
+            if (bases[i] instanceof org.python.util.PyMetaClass) {
+                try {
+                    return 
(PyObject)bases[i].getClass().getConstructor(pyClass CtrSignature).newInstance(
+                        new Object[] { name, new PyTuple(bases), dict, 
proxyClass });
+                } catch (Exception e) {
+                    throw Py.TypeError("meta-class fails to supply proper 
ctr:"+bases[i].safeRepr());
+                }
+            }
              if (!(bases[i] instanceof PyClass)) {
                  PyObject c = bases[i].__class__;
                  // Only try the meta-class trick on __class__'s that are

It's the same as yours, except that it goes before the PyClass check, so 
that an object that "extends PyClass implements PyMetaClass" will be 
treated as a metaclass.


>plus an empty org.python.util.PyMetaClass interface
>could make into the code, no problem with that.

Thanks!  This will be a big help for my project, as now I'll be able to use 
ComputedAttributes in TransWarp without having to worry about there being 
no way to do them in Jython.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 11:29 AM 7/15/01 +0000, Finn Bock wrote:
>[Samuele]
>
> >[a patch]
> >plus an empty org.python.util.PyMetaClass interface
> >could make into the code, no problem with that.
> >
> >I can play the good guy <wink> and if it's OK for Finn, it can be committed.
>
>I haven't tested it, but if Samuele's patch would work for you Phillip,
>then I see no problem in adding it. But ...

Let me play with it today.  I think it needs to be repositioned from an 
else to the first if() in order to work properly.



> >The whole point is that the patch will last until 2.2 and maybe survive to
> >that.
>
>Exactly! If this change turns out to interact poorly with the up-comming
>2.2 "descr" change it might be removed again. So for the moment the
>PyMetaClass hook should be considered an experimental feature.
>
>OTOH, if you can deliver an ExtensionClass compatible module, then it is
>an excellent argument in favor of keeping the proposed PyMetaClass hook.

My initial goal is just to provide an emulation of ExtensionClass' 
MethodObject and ComputedAttribute classes for use with TransWarp.  But as 
time permits I'd like to experiment with replicating EC's Acquisition and 
Persistent modules.  I'll be happy to release anything I do under 
Jython-compatible licensing.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 03:42 AM 7/15/01 +0200, Samuele Pedroni wrote:

>So after the trouble of  a few posts and of making me propose a bad and not
>working hack, you came out
>with some actual code <wink>.
>
> > Nonetheless, I understand that some things just can't or don't make it into
> > a project, for whatever reasons.
>The situation is as follow: in principle the following patch along the line of
>your code

I'll give it a shot.  I think the PyMetaClass check needs to occur *before* 
the PyClass check, though, since the idea is to extend PyClass - if I were 
going to copy all of PyClass' code into PyExtClass, I wouldn't need the 
patch.  :)


>plus an empty org.python.util.PyMetaClass interface
>could make into the code, no problem with that.
>
>I can play the good guy <wink> and if it's OK for Finn, it can be committed.

Fantastic.  I'll see what I can do with it today, and then submit a working 
patch.


>The whole point is that the patch will last until 2.2 and maybe survive to
>that.
>But I'm not willing to commit on the actual internals design or the patch as
>something here to stay.
>The internals after 2.2 are something that should be designed to stay, that's
>my goal.
>E.g. the last PyJavaClasses related bug I had to solve I should resort to an
>hack because
>of the internals... this should be fixed (clearly not an easy thing, perfectly
>aware of that).
>
>So if you will not call me a bad guy <wink> if what you build on top of 2.1
>internals will no longer work with 2.2,
>I think you can have the feature. Not really a technical point, more a
>"political" one, but not a personal ...

I understand.  As of 2.2, I'm sure CPython ExtensionClasses will be getting 
some redesigning also.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

[Samuele]

>[a patch]
>plus an empty org.python.util.PyMetaClass interface
>could make into the code, no problem with that.
>
>I can play the good guy <wink> and if it's OK for Finn, it can be committed.

I haven't tested it, but if Samuele's patch would work for you Phillip,
then I see no problem in adding it. But ...

>The whole point is that the patch will last until 2.2 and maybe survive to
>that.

Exactly! If this change turns out to interact poorly with the up-comming
2.2 "descr" change it might be removed again. So for the moment the
PyMetaClass hook should be considered an experimental feature.

OTOH, if you can deliver an ExtensionClass compatible module, then it is
an excellent argument in favor of keeping the proposed PyMetaClass hook.

regards,
finn

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

So after the trouble of  a few posts and of making me propose a bad and not
working hack, you came out
with some actual code <wink>.

> Nonetheless, I understand that some things just can't or don't make it into
> a project, for whatever reasons.
The situation is as follow: in principle the following patch along the line of
your code

Index: Py.java
===================================================================
RCS file: /cvsroot/jython/jython/org/python/core/Py.java,v
retrieving revision 2.46
diff -u -5 -r2.46 Py.java
--- Py.java 2001/07/03 20:20:27 2.46
+++ Py.java 2001/07/15 01:26:25
@@ -1404,10 +1404,11 @@
                                      Class proxyClass) {
         return makeClass(name, bases, code, doc, proxyClass, null);
     }


+    private static Class[] pyClassCtrSignature =
{String.class,PyTuple.class,PyObject.class,Class.class};
     public static PyObject makeClass(String name, PyObject[] bases,
                                      PyCode code, PyObject doc,
                                      Class proxyClass,PyObject[]
closure_cells)
     {
         PyFrame frame = getFrame();
@@ -1430,11 +1431,19 @@
                                        bases[i].safeRepr());
                 }
                 return c.__call__(new PyString(name),
                                   new PyTuple(bases),
                                   dict);
+            } else if (bases[i] instanceof org.python.util.PyMetaClass) {
+                try {
+                    return
(PyObject)bases[i].getClass().getConstructor(pyClassCtrSignature).newInstance(
+                            new Object[] { name, new PyTuple(bases), dict,
proxyClass });
+                } catch(Exception e) {
+                    throw Py.TypeError("meta-class fails to supply proper ctr:
"+bases[i].safeRepr());
+                }
             }
+
         }

         return new PyClass(name, new PyTuple(bases), dict, proxyClass);
     }

plus an empty org.python.util.PyMetaClass interface
could make into the code, no problem with that.

I can play the good guy <wink> and if it's OK for Finn, it can be committed.

The whole point is that the patch will last until 2.2 and maybe survive to
that.
But I'm not willing to commit on the actual internals design or the patch as
something here to stay.
The internals after 2.2 are something that should be designed to stay, that's
my goal.
E.g. the last PyJavaClasses related bug I had to solve I should resort to an
hack because
of the internals... this should be fixed (clearly not an easy thing, perfectly
aware of that).

So if you will not call me a bad guy <wink> if what you build on top of 2.1
internals will no longer work with 2.2,
I think you can have the feature. Not really a technical point, more a
"political" one, but not a personal ...

regards, Samuele Pedroni.

[Jython-dev] ya import logic rework

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

I have posted a patch to SF that should solve
438108 __getitem__ called when it shouldn't?
and other import logic corner cases and increase CPython comp.

regards, Samuele Pedroni.

PS: the patch it's a real rework of the involved code along the line of CPython
counterpart,
patching again the patched JPython logic seemed to me pointless.

[Jython-dev] [ jython-Patches-441369 ] ya import logic rework

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Finn Bock (bckfnn)
Summary: ya import logic rework

Initial Comment:
The patch should increase CPython comp
wrt import logic and solve

438108 __getitem__ called when it shouldn't? 

and other import bugs. The code is now more similar
to the CPython counterpart. Trying just to patch
the patched JPython logic again -I think - would not 
have been the right solution.

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

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

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 11:11 PM 7/14/01 +0200, Samuele Pedroni wrote:
> > Being that the only way is to do it from Java, is there anyway to extend
> > PyClass, while still having the meta-hook take effect?  I'd like to extend
> > PyClass without having to copy all its code, just to get around the
> > instanceof test.
>My tricky code does that or a java version of it, or something similar.
>Basically you have to pass a prototype obj that have a __class__ attr set
>to a callable that taking the name,bases and dict args returns a constructed
>instance
>of your subclass of PyClass.

The "tricky code" doesn't work for inheritance.  Note that in the example 
you gave, subclassing from Z will *not* trigger the metaclass 
hook.  Basically, it's because you're using a phony metaclass to stand-in 
for the *real* metaclass, which means it has to figure out which base is 
the dummy, and get rid of it.  Once it's been gotten rid of, a subclass is 
no longer treated as having a metaclass base.


> > Could there perhaps be instead a interface that Java extenders of PyClass
> > could use to signal their desire to be a meta/pseudo-class?  Would a patch
> > to the meta-hook that recognizes such an interface be acceptable?  Then I
> > could subclass PyClass in Java, "implement" that interface, and everything
> > would, I believe, be just fine.
>The answer is No. Because:
>- there are tricks to achieve the same without patching the internals

Not with the trick you gave, in either Java or Python, due to the 
inheritance issue.


>- I don't have time, now, to make up my mind about that, sorry.

The implementation would consist of three lines added to Py.java:

         if (bases[i] instanceof PyMetaClass) {
             return ((PyMetaClass)bases[i]).newClassObject(name,new 
PyTuple(bases),dict);
         }

Plus the declaration of the PyMetaClass interface and its single method, 
"newClassObject".  I have already tested this implementation by creating a 
Java PyExtClass which extends PyClass and implements PyMetaClass.  It 
*does* work with inheritance.  My ExtensionClass.java module then exports 
an instance of PyExtClass which can then be used as a base class for Python 
classes, and the above meta-hook is correctly triggered.

So, with a very small patch, it would be possible to create proper 
metaclasses (i.e. inheritable ones) from Java by extending PyClass and 
PyInstance.

Nonetheless, I understand that some things just can't or don't make it into 
a project, for whatever reasons.


>OTOH very probably the actual shape of PyClass and PyInstance will change
>in order to support the descr changes in jython 2.2. If you have proposals,
>want to help to integrate that changes in jython I'll be happy to hear from
>you.

I'm not yet familiar enough with the 2.2 proposals...  I'm still getting my 
head wrapped around 2.1, actually.  :)

[Jython-dev] Regression test suite.

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

I just checkin in a new CVS module called bugtests which contains all
the small test cases I collected during and after the errata era. Even
while the tests are somewhat rough, I believe that they are worth
keeping and maintaining.

   http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jython/

Currently the support module is very WwinNT specific. Feel free to send
patches to make it run on *nixes.

The README.txt file contains information needed for running the test
suite.

regards,
finn

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

Hi.

> At 02:12 AM 7/14/01 +0200, Samuele Pedroni wrote:
> >First, for CPython 2.2 GvR is actively working on redesigning CPython
> >internals (see PEPs 252,253) in order to remove the CPython type/class
> >dicotomy, this will
> >also allow to write CPython extension that result in class-like objects,
> >e.g. subclassing from python will work. This will obsolete ExtensionClasses.
>
> I'm aware of these efforts.  However, while they will eliminate the need
> for the "ExtensionClass" object itself, the various modules and classes
> written using ExtensionClasses will still need to exist (and will need
> rewriting).  For example, ComputedAttribute and MethodObject, two items I'm
> especially interested in porting to Jython.
I can't help here, I don't know what kind of (compatibility) path will take
ExtensionClasses
and at least DC stuff based on them after the changes.

> >[snip]
> > > class ExtensionInstance(PyInstance):
> >[snip]
> >
> >This makes really no sense (it is not intended to work), if one considers
what
> >the internal role of PyInstance instances is.
>
> I don't understand.  I want to change the behavior of PyInstance - that's
> the point of ExtensionClasses, to be able to change the behavior of object
> instances in ways that can't be reached from Python.  I was just hoping to
> shortcut the process by using Python instead of Java to do it.
My point is that you were just hoping too much <wink>, if you consider how
PyInstances
work and how subclassing of java classes from jython works. Yes, you should
subclass PyInstance in java, it is the only clean way. The same holds for
PyClass.
Of course you can use the pure python version of Don Beaudry hook,
if that is enough.

> Being that the only way is to do it from Java, is there anyway to extend
> PyClass, while still having the meta-hook take effect?  I'd like to extend
> PyClass without having to copy all its code, just to get around the
> instanceof test.
My tricky code does that or a java version of it, or something similar.
Basically you have to pass a prototype obj that have a __class__ attr set
to a callable that taking the name,bases and dict args returns a constructed
instance
of your subclass of PyClass.

> Could there perhaps be instead a interface that Java extenders of PyClass
> could use to signal their desire to be a meta/pseudo-class?  Would a patch
> to the meta-hook that recognizes such an interface be acceptable?  Then I
> could subclass PyClass in Java, "implement" that interface, and everything
> would, I believe, be just fine.
The answer is No. Because:
- there are tricks to achieve the same without patching the internals
- I don't have time, now, to make up my mind about that, sorry.

OTOH very probably the actual shape of PyClass and PyInstance will change
in order to support the descr changes in jython 2.2. If you have proposals,
want to help to integrate that changes in jython I'll be happy to hear from
you.

regards, Samuele Pedroni.

Sorry if I don't seem much helpful but the issues are complicated and I don't
have much time for them, not now.

PS:  if you look at PEP 252 descr.__get__ is very similar to __of__ .

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

At 02:12 AM 7/14/01 +0200, Samuele Pedroni wrote:
>First, for CPython 2.2 GvR is actively working on redesigning CPython
>internals (see PEPs 252,253) in order to remove the CPython type/class
>dicotomy, this will
>also allow to write CPython extension that result in class-like objects,
>e.g. subclassing from python will work. This will obsolete ExtensionClasses.

I'm aware of these efforts.  However, while they will eliminate the need 
for the "ExtensionClass" object itself, the various modules and classes 
written using ExtensionClasses will still need to exist (and will need 
rewriting).  For example, ComputedAttribute and MethodObject, two items I'm 
especially interested in porting to Jython.

I need these in order to have source portability for my TransWarp toolkit, 
so the API must be an exact match.



>[snip]
> > class ExtensionInstance(PyInstance):
>[snip]
>
>This makes really no sense (it is not intended to work), if one considers what
>the internal role of PyInstance instances is.

I don't understand.  I want to change the behavior of PyInstance - that's 
the point of ExtensionClasses, to be able to change the behavior of object 
instances in ways that can't be reached from Python.  I was just hoping to 
shortcut the process by using Python instead of Java to do it.

Being that the only way is to do it from Java, is there anyway to extend 
PyClass, while still having the meta-hook take effect?  I'd like to extend 
PyClass without having to copy all its code, just to get around the 
instanceof test.

Could there perhaps be instead a interface that Java extenders of PyClass 
could use to signal their desire to be a meta/pseudo-class?  Would a patch 
to the meta-hook that recognizes such an interface be acceptable?  Then I 
could subclass PyClass in Java, "implement" that interface, and everything 
would, I believe, be just fine.


>see above BUT in the future (2.2)
>jython will try to mimick as long as possible the new CPython redesign, this
>should results in more polished internals.
>That's the direction to go and work for, and as I said ExtensionClasses on the
>long run will become obsolete.

AFAICT, all that will go away is the need to have a full C reimplementation 
of the Python class type.  In order to do the things that ExtensionClass 
exists *for*, one will still need to extend PyClass, PyInstance, and their 
equivalents in CPython.  That is, unless features like __of__(), 
__class_init__(), inheritedAttribute(), __call_method__() and the like 
become part of the Python language standard, and I haven't seen any PEP's 
for them.

Re: [Jython-dev] Metaclasses, _doget, and ExtensionClasses

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

Hi.

[Philip J. Eby]
> Hi!  I've recently embarked upon the somewhat quixotic mission of porting
> selected portions of Jim Fulton's ExtensionClasses to Jython 2.1a2.
First, for CPython 2.2 GvR is actively working on redesigning CPython
internals (see PEPs 252,253) in order to remove the CPython type/class
dicotomy, this will
also allow to write CPython extension that result in class-like objects,
e.g. subclassing from python will work. This will obsolete ExtensionClasses.

Second Jython and metaclasses:  Jython supports the Don Beaudry hook
 http://www.python.org/doc/essays/metaclasses/
but implements a subtly different triggering policy, because
the CPython type/class separation does not really exists in jython: given
class C: pass

C.__class__ fails in CPython but not in jython
and callable(type(C)) is false in CPython but true in jython,

so the !instanceof PyClass policy in order to mimick python behaviour.

> I found out a few interesting things.  First, it is possible to extend
> PyClass from Python, but the way the metaclass hook is implemented, it has
> no effect.  Since an instance of your extended PyClass is an "instanceof"
> PyClass, its meta-nature is ignored by Py.makeclass.  Interestingly, this
> means it is also impossible to write an ExtensionClass-like class object in
> Java, at least if it extends PyClass.
The following hack seems to work, but I must honestly say, it is not supported:

from org.python.core import PyClass

class PyClassMirror(PyClass):
  def __init__(self,name,bases,dict):
    bases = bases[2:]
    print "newpyclass",name,bases,dict
    PyClass.__init__(self,name,bases,dict)

  def toString(self):
    return "<"+PyClass.toString(self)+">"

class Proto: pass
PyClassMirrorProto = Proto()
PyClassMirrorProto.__class__=PyClassMirror

print "*****"

class Z(PyClassMirrorProto):
  pass

print repr(Z)

z=Z()

z.a=3

It works because PyClassMirrorProto.__class__ __call__ will run Z constructor
which calls the PyClass ctr.
To reproduce this with java code is left as an exercise to the reader <wink>.

[snip]
> class ExtensionInstance(PyInstance):
[snip]

This makes really no sense (it is not intended to work), if one considers what
the internal role of PyInstance instances is.
Already

class Z(PyInstance): pass
z=Z()
z.a=3

goes in an infinity recursion. I wouldn't call this a bug.
OTOH one can subclass PyInstance in Java.

> Anyway, I'm not sure what I should be asking here.  At this point, I'm
> reasonably certain I can do what I need to directly in Java if I could
> extend PyClass and still have the metaclass hook take effect.  Any
> suggestions would be appreciated.
>
see above BUT in the future (2.2)
jython will try to mimick as long as possible the new CPython redesign, this
should results in more polished internals.
That's the direction to go and work for, and as I said ExtensionClasses on the
long run will become obsolete.

Samuele Pedroni.

[Jython-dev] [ jython-Support Requests-441102 ] Unable to download 2.0 sources

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

Support Requests item #441102, was opened at 2001-07-13 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=212867&aid=441102&group_id=12867

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Bill Krueger (wkrue1)
>Assigned to: Finn Bock (bckfnn)
Summary: Unable to download 2.0 sources

Initial Comment:
I'm getting the error msg: "linefeed expected in
cvsroot/jython/org/python/core/Java2Accessability.java,v"
when I do a checkout using the -r Release_2_0 option to
get the release 2.0 sources. 
The cvs command is "cvs -z3
-d:pserver:ano...@cv...:/cvsroot/jython
co -r Release_2_0 jython" and it downloads quite a bit
of code before the error hits. 

I'm wanting to reproduce a production environment that
currently uses jython 2.0  with some modifications and
using the 2.1alpha seems a bit of a risk. Any help
would be appreciated. 

thanks,

billK

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

>Comment By: Finn Bock (bckfnn)
Date: 2001-07-13 11:55

Message:
Logged In: YES 
user_id=4201

This problem is caused by a manual edit of the CVS 
repository. I hope we have the problems resolved soon.

regards,
finn

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

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

[Jython-dev] [ jython-Support Requests-441102 ] Unable to download 2.0 sources

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

Support Requests item #441102, was opened at 2001-07-13 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=212867&aid=441102&group_id=12867

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Bill Krueger (wkrue1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to download 2.0 sources

Initial Comment:
I'm getting the error msg: "linefeed expected in
cvsroot/jython/org/python/core/Java2Accessability.java,v"
when I do a checkout using the -r Release_2_0 option to
get the release 2.0 sources. 
The cvs command is "cvs -z3
-d:pserver:ano...@cv...:/cvsroot/jython
co -r Release_2_0 jython" and it downloads quite a bit
of code before the error hits. 

I'm wanting to reproduce a production environment that
currently uses jython 2.0  with some modifications and
using the 2.1alpha seems a bit of a risk. Any help
would be appreciated. 

thanks,

billK

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

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

[Jython-dev] _winreg in Jython?

[Ben K. <ben...@ya...>]

Hello,

I am in the process of making a jdbc/Swing app in Java.  I would like to pull the username from the registry to autofill a field.  In Python it is easy:

import _winreg
x=_winreg.ConnectRegistry(None,_winreg.HKEY_LOCAL_MACHINE);
y= _winreg.OpenKey(x,"Network\Logon");
username = _winreg.QueryValueEx(y,"username")[0]
print username

Unfortunately this function is not available in Java (or Jython).  Are there any plans to incorporate this into Jython.  If there were a way that I could duplicate this feature in the "Core Python" language, I could simply compile it as a java app and that would be it.  Thanks in advance for any information.

Best regards,

Ben 

[Jython-dev] Metaclasses, _doget, and ExtensionClasses

[Phillip J. E. <pj...@te...>]

Hi!  I've recently embarked upon the somewhat quixotic mission of porting 
selected portions of Jim Fulton's ExtensionClasses to Jython 2.1a2.

Initially, I tried to use Python metaclasses to do this, coupled with 
Jython's ability to extend Java classes, to try and extend 
org.python.core.PyInstance and org.python.core.PyClass.  The results were 
just successful enough to lead me down the killer rabbit hole for most of 
the day.

I found out a few interesting things.  First, it is possible to extend 
PyClass from Python, but the way the metaclass hook is implemented, it has 
no effect.  Since an instance of your extended PyClass is an "instanceof" 
PyClass, its meta-nature is ignored by Py.makeclass.  Interestingly, this 
means it is also impossible to write an ExtensionClass-like class object in 
Java, at least if it extends PyClass.

Okay, so as a temporary workaround, I manually created instances of my 
ExtensionClass, so that I could find out if things worked otherwise.

I want to implement the ExtensionClass __of__() protocol, wherein an object 
retrieved from another object gets its __of__() method called, and the 
return value is used in place of the original object.  I discovered that 
Jython's _doget() protocol is almost identical, except that it is only 
applied to items retrieved from a class, not the instance 
dictionary.  Okay, close enough for an experiment, so I overrode _doget 
like this:

class ExtensionInstance(PyInstance):

     def _doget(self,container,foundIn):

         if container is None:
             return self

         of = self.ifindclass('__of__',0)

         # This works
         return id(of)

         # This doesn't - even if I just return self

         if of is None:
             return self

         return of(self,container)


Strangely, if _doget returns an object like an integer or string, it 
works.  If _doget returns self, Jython hangs for an extended period (I 
suspect building up to a stack overflow error).  Hm.

Anyway, I'm not sure what I should be asking here.  At this point, I'm 
reasonably certain I can do what I need to directly in Java if I could 
extend PyClass and still have the metaclass hook take effect.  Any 
suggestions would be appreciated.

[Jython-dev] jdbm support : A start...

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

I'm forwarding this, in case someone has time to play with it.
A polished version would be a great thing for jython.
Thanks to Magnus.

regards, Samuele Pedroni.

PS: I think there should be a way to have the module called jdbm too.


------------- Begin Forwarded Message -------------

From: "Magnus Lie Hetland" <ml...@id...>
To: "Samuele Pedroni" <pe...@in...>
Cc: "Amund Tveit" <am...@el...>
Subject: A start...
Date: Tue, 10 Jul 2001 18:38:03 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Keywords: 

Hi!

I just threw together something which may at least
be a starting point for a jdbm module. It is (AFAIK)
fully functional, but can probably be improved in
many ways. I had to call it something other than
jdbm since that is the name of the Java module, so
I called it jdbpy. It should probably be imported
through anydbm anyway, so... :)

Here is the code:

------------ begin jdbpy ------------

"""A thin wrapper around jdbm.

The open function returns a dictionary object which is a thin
wrapper around a jdbm.BTree object. The jdbm database can be
found at jdbm.sourceforge.net.
"""

_os = __import__('os')
import __builtin__

_open = __builtin__.open

import jdbm

error = IOError                # For anydbm (?)

class _Database:

    def __init__(self, file):
        self._manager = jdbm.JDBMRecordManager(file)
        self._hash = self._manager.getHashtable('jdbpy')

    def __getitem__(self, key):
        try:
            val = self._hash.get(key)
        except:
            val = None
        if not val:
            raise KeyError(key)
        return val

    def __setitem__(self, key, value):
        self._hash.put(key, value)

    def __delitem__(self, key):
        self._hash.remove(key)

    def __len__(self):
        return len(self.keys()) # Horribly inefficient

    def has_key(self, key):
        try:
            result = self._hash.get(key)
            if result:
                return 1
        except:
            pass
        return 0

    def keys(self):
        e = self._hash.keys()
        result = []
        while e.hasMoreElements():
            result.append(e.nextElement())
        return result

    def close(self):
        self._manager.close()
        del self._manager
        del self._hash

    def __del__(self):
        self.close()

def open(file, flag = None, mode = None):
    # flag and mode arguments are currently ignored
    return _Database(file)

------------- end jdbpy -------------

Here is a simple patch for anydbm, so it works with jdbm
(jdbpy):

------------- begin diff -------------

*** /home/idi/f/mlh/python/Python-2.1/Lib/anydbm.py Sun Feb 18 04:30:53 2001
--- anydbm.py Tue Jul 10 18:23:12 2001
***************
*** 10,16 ****
          import anydbm
          d = anydbm.open(file, 'w')

! The returned object is a dbhash, gdbm, dbm or dumbdbm object,
  dependent on the type of database being opened (determined by whichdb
  module) in the case of an existing dbm. If the dbm does not exist and
  the create or new flag ('c' or 'n') was specified, the dbm type will
--- 10,16 ----
          import anydbm
          d = anydbm.open(file, 'w')

! The returned object is a dbhash, gdbm, dbm, jdbm or dumbdbm object,
  dependent on the type of database being opened (determined by whichdb
  module) in the case of an existing dbm. If the dbm does not exist and
  the create or new flag ('c' or 'n') was specified, the dbm type will
***************
*** 48,54 ****
  except:
      error = "anydbm.error"

! _names = ['dbhash', 'gdbm', 'dbm', 'dumbdbm']
  _errors = [error]
  _defaultmod = None

--- 48,54 ----
  except:
      error = "anydbm.error"

! _names = ['dbhash', 'gdbm', 'dbm', 'jdbpy', 'dumbdbm']
  _errors = [error]
  _defaultmod = None

-------------- end diff --------------

Adding a check at the beginning of whichdb.py would simply entail checking
for foobar.db and foobar.lg if the database is called foobar. (Or something
like that - some simple analysis of the contents may be necessary; I
don't know. But I would guess that it would take 10-15 minutes if one
just looked at it :)

It may be that using the jdbm module is not the best choice - that
jdbm.btree would be more scalable... I don't know.

And... If jdbm is added to Jython's capabilities, it could certainly be
added to the anydbm.py of the standard distribution. The only difference
is that you would have to check _one_ more possibility before falling
back on dumbdm... And if you are going to fall back on that, performance
is probably not an issue anyway ;)

That way, the same module could be used for CPython and Jython - I assume
that is a goal?

Well - that's it for now.

- M

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick



------------- End Forwarded Message -------------

Re: [Jython-dev] Jython 2.1 and JVM 1.3

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

[Bryn]

>Actually, 2.1 even seems to work with Java 1.4, ...

Yes; apart from some warnings when compiling the jython sources.
Aparently we get a warning because we use "assert" as an identifier.
It'll be fixed before 2.1 is released.

regards,
finn

RE: [Jython-dev] Jython 2.1 and JVM 1.3

[<br...@je...>]

Actually, 2.1 even seems to work with Java 1.4, which my previous version
(1.1 + 09) did not.
I've been using 1.3 for over a year now with JPython, and upgraded to Jython
2.1 a couple of weeks ago with no problems.

Bryn

> -----Original Message-----
> From:	bc...@wo... [SMTP:bc...@wo...]
> Sent:	Wednesday, July 11, 2001 3:34 PM
> To:	'jyt...@li...'
> Cc:	James Deller
> Subject:	Re: [Jython-dev] Jython 2.1 and JVM 1.3
> 
> [James Deller]
> 
> >Am interested in your Jython interpreter for possible use in an on-going 
> >project.  Is 2.1 compatible with JVM 1.3??  Haven't run across anything
> on 
> >your site stating that it is..
> 
> Well, I have not yet run across any thing that indicate jython-2.1a1
> isn't compatible with JDK1.3.
> 
> You can safely assume it is compatible. If you discover a situation
> where it isn't, please report it as bug on our bug tracker:
> 
>    http://sourceforge.net/tracker/?group_id=12867&atid=112867
> 
> regards,
> finn
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] Jython 2.1 and JVM 1.3

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

[James Deller]

>Am interested in your Jython interpreter for possible use in an on-going 
>project.  Is 2.1 compatible with JVM 1.3??  Haven't run across anything on 
>your site stating that it is..

Well, I have not yet run across any thing that indicate jython-2.1a1
isn't compatible with JDK1.3.

You can safely assume it is compatible. If you discover a situation
where it isn't, please report it as bug on our bug tracker:

   http://sourceforge.net/tracker/?group_id=12867&atid=112867

regards,
finn