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

Re: [Jython-dev] Jython and native java merged with simplicity

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

Hi, I found your mail a bit confusing, maybe there was just too
much meta comments <wink>.

I see three different points:
- jython is slow vs. java
- subclassing a PyObject subclass from jython have problem with mutability of
the instances of the resulting class
  This should be solved, probably in 2.2, given that to have a jython 2.2 we
should somehow implement the descr changes
  happened to CPython
- a way to solve (partially) both the above problems, although in my opinion
they are unrelated.

In any case adding new keywords and strange semantics is a no-go.

Although I have maybe understood what was the idea behind your words, I don't
want to try to re-explain it confusing
things further, so please please restate it more clearly...

in any case this is an open source projects, prosal and patches are always
welcome.

Samuele Pedroni.



----- Original Message -----
From: john coppola <joh...@ya...>
To: <jyt...@li...>
Sent: Tuesday, August 07, 2001 2:03 AM
Subject: [Jython-dev] Jython and native java merged with simplicity


> After examining the Jython JAPI, it is quite clear
> that the internal operation of the Interpreter is
> quite different.  The jAPI of Jython leverages java's
> object oriented nature to implement a Python
> equivalent in  java.  The jython API has some
> interesting features but has some flaws as well.  I
> would like to see these things changed in future
> releases of Jython:
>
> It is very easy to create a true Python class in Java
> using the Jython Api.  But, there is, as usual a
> better way to go about things which would make things
> run much faster and with greater flexibility.
>
> Now, one could create a true Python class in java, but
> the performance boost is minimal and not worth the
> time.
>
> Native java code runs much faster.  Proof of this is
> the cPickle module implementation in java.  The speed
> of "jPickle" is the same speed as cPickle.
>
> Here is a code comparison for a simple program:
> from time import time
> def test():
>     start = time()
>     total = 0.0
>     for i in range(0,1000000):
>         total = total + i + i*2.0
>     print time()- start
>
> This test on my computer:
>   python2.0:                     2.77 seconds
>   jython2.1a1:                   7.40 seconds
>   native java:                   0.014 seconds
>
> 197 times faster than Python
> 528 times faster than Jython
>
> It would be nice if a python class could leverage the
> speed of java, while having the flexibility of Python.
> We should in theory be able to do this using a Mix-In
> approach.
>
> public class jSpam implements PyObject {
>     public pyOb = new PyObject();
>
>     public void setOb(PyObject ob) {
>         pyOb = ob;
>     }
> }
>
>
> import jSpam # true java class
> class Dummy: pass
>
> Class Foo(Dummy,jSpam):
>     def __init__(self,name):
>         self.name=name
>
> Now, in theory this code should work:
>
> foo=Foo("foo")
>
> This code bombs because inhereting from jSpam has
> interfered with our inheritence from Dummy.
>
> The reason it bombs is because we cannot set
> attributes on the java class we inherited from.  This
> makes sense since java is statically typed. We should
> be able to set attributes on the Foo portion of the
> object.  Jython does not understand this.
>
>
> We really need to include a feature in Jython that can
> leverage Java's speed with a simple api layer to do
> so.
> For lack of better terminology I'll call it a ghosting
> and skeletons.
>
> Ghosting is the layer in that will provide hooks into
> python types mapped into java skeleton classes. So
> everytime we change a python attribute, the attribute
> is updated in the java skeleton automatically.  This
> will in effect pin the Python class to a java class
> removing some of the dynamic flexibility we have with
> the python classes, but the speed gain is tremendous,
> so worth our while.
>
> so in java maybe we have:
>
>    public class mySkeleton implements ghosting
>
> the Ghosting interface are the hooks needed by Jython
> to map a Python object to it's skeleton in java
>
> perhaps syntax in Jython would look like:
>    from spam import Spam with jSpam skeleton
>
>    This would import Spam from the spam module and
>    associate the Spam class with the jSpam skeleton.
>
> Alternate syntax may look like:
>    from spam import Spam with jSpam skeleton as Spam1
>    from spam import Spam with jSpam2 skeleton as Spam2
>
> Where Spam1 and Spam2 have been linked with different
> java skeletons.
>
> A system such as this would provide an easy way to
> utilize java's speed and enable Jython to run several
> times faster than cPython where computationally
> intensive algorithms could be done in the native java
> skeleton class.
>
> John Coppola
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Jython and native java merged with simplicity

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

-> so in java maybe we have:
-> 
->    public class mySkeleton implements ghosting

[ munch ]

Hi, John,

there is a problem with adding keywords into Jython that aren't
in CPython: then Jython is no longer "Python", but is rather
"Python-like".

In my project, I'm writing code that works in both.  It's not clear
in the end how necessary this approach will be, or how useful, but
it's something to keep in mind.

As far as speed: why not simply "harden" Jython classes into
Java when you have it all worked out?  My plan is to use
Jython partly as a rapid prototyping tool, and then (as necessary)
rewrite classes into Java.

--t

[Jython-dev] Jython and native java merged with simplicity

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

After examining the Jython JAPI, it is quite clear
that the internal operation of the Interpreter is
quite different.  The jAPI of Jython leverages java's
object oriented nature to implement a Python
equivalent in  java.  The jython API has some
interesting features but has some flaws as well.  I
would like to see these things changed in future
releases of Jython:

It is very easy to create a true Python class in Java
using the Jython Api.  But, there is, as usual a
better way to go about things which would make things
run much faster and with greater flexibility.

Now, one could create a true Python class in java, but
the performance boost is minimal and not worth the
time.

Native java code runs much faster.  Proof of this is
the cPickle module implementation in java.  The speed
of "jPickle" is the same speed as cPickle.

Here is a code comparison for a simple program:
from time import time
def test():
    start = time()
    total = 0.0
    for i in range(0,1000000):
        total = total + i + i*2.0
    print time()- start

This test on my computer:
  python2.0:                     2.77 seconds
  jython2.1a1:                   7.40 seconds
  native java:                   0.014 seconds

197 times faster than Python
528 times faster than Jython

It would be nice if a python class could leverage the
speed of java, while having the flexibility of Python.
We should in theory be able to do this using a Mix-In
approach.

public class jSpam implements PyObject {
    public pyOb = new PyObject();

    public void setOb(PyObject ob) {
        pyOb = ob;
    }
}


import jSpam # true java class 
class Dummy: pass

Class Foo(Dummy,jSpam):
    def __init__(self,name):
        self.name=name

Now, in theory this code should work:

foo=Foo("foo")

This code bombs because inhereting from jSpam has
interfered with our inheritence from Dummy.

The reason it bombs is because we cannot set
attributes on the java class we inherited from.  This
makes sense since java is statically typed. We should
be able to set attributes on the Foo portion of the
object.  Jython does not understand this.


We really need to include a feature in Jython that can
leverage Java's speed with a simple api layer to do
so.
For lack of better terminology I'll call it a ghosting
and skeletons.

Ghosting is the layer in that will provide hooks into
python types mapped into java skeleton classes. So
everytime we change a python attribute, the attribute
is updated in the java skeleton automatically.  This
will in effect pin the Python class to a java class
removing some of the dynamic flexibility we have with
the python classes, but the speed gain is tremendous,
so worth our while.

so in java maybe we have:

   public class mySkeleton implements ghosting

the Ghosting interface are the hooks needed by Jython
to map a Python object to it's skeleton in java

perhaps syntax in Jython would look like:
   from spam import Spam with jSpam skeleton

   This would import Spam from the spam module and
   associate the Spam class with the jSpam skeleton.

Alternate syntax may look like:
   from spam import Spam with jSpam skeleton as Spam1
   from spam import Spam with jSpam2 skeleton as Spam2

Where Spam1 and Spam2 have been linked with different
java skeletons.

A system such as this would provide an easy way to
utilize java's speed and enable Jython to run several
times faster than cPython where computationally
intensive algorithms could be done in the native java
skeleton class.

John Coppola


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

[Jython-dev] diff - compile error

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

I had to make the change below to get this to compile with jdk1.3.0_02
on Windoze.

RCS file: /cvsroot/jython/jython/org/python/modules/time.java,v
retrieving revision 2.16
diff -r2.16 time.java
238,239c238,239
<             cal.set(Calendar.DST_OFFSET,
<                     dst * cal.getTimeZone().getDSTSavings());
---
>    SimpleTimeZone sZone = (SimpleTimeZone)cal.getTimeZone();
>             cal.set(Calendar.DST_OFFSET, dst * sZone.getDSTSavings());

Re: [Jython-dev] Mini PEP: IgnoreMethodTag

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

[Stuart Swerdloff]

>If the dummy exception would appear in the Java source,
>it might be helpful to name the Exception so that the
>context of PyJava / Jython is clear, e.g.
>JythonIgnoreMethodTag
>(although IgnoreMethodTag might have this context embedded
>by virtue of the package it will contained in... which raises the
>question of which package ). 

It have to be added to org.python.core.

>Otherwise, this seems to match
>the pattern used by Cloneable more or less.

regards,
finn

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

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

[Titus Brown]

>Hi, I'm having an interesting problem:
>
>in the following piece of code, when interpreted,
>
>---
>try:
>   (a, b, c) = string.split(s)
>except ValueError:
>   print 'ERROR in input string, skipping line: %s' % (s,)
>--
>
>if the split of s does not contain three elements, a ValueError
>is raised & caught appropriately.
>
>HOWEVER, if I use jythonc to compile the file into a .class, it turns
>out that a KeyError is raised in the same place for the same piece of
>code.

This is obviously a bug and I have added a bug report about it.

regards,
finn

Re: [Jython-dev] building from cvs

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

[Brian Parker]

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

As Robert said, the comment in build.xml and the documentation was not
in sync with the actual usage. I have updated the comment as well as the
the documentation for compiling Jython sources:

   http://www.jython.org/docs/compile.html

regards,
finn

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

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

[Wiwih "Will" Gunadi]

>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

In 2.1beta1 I expect parts of the PyXML package to be shipped within the
jython distribution. Based on this new setup I managed to compile a very
simple xml.sax application with jythonc.

In my main program I needed to a dummy function like this:

def dummy_jythonc():
    import xml.sax.drivers2.drv_xmlproc
    import encodings.utf_16_be
    import dumbdbm

It causes the dynamicly loaded modules to be visible to jythonc during
compilation.

The test application is available as test313.py and test313c.py here:

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

This probably doesn't fix your particular problem, but I hope it will
become easier to use xml.sax as the work progress.

regards,
finn

[Jython-dev] How can I use Mysql under jython ?

[syKim <re...@ne...>]

Hello 

I am trying web program with jython..

It have to use database. and, I tried mysql..

in python, Mysql-python module exist (a kind of plug-in module)

but, it is just occasion of Cpython..

How can I use Mysql under jython?  Is it possible?

Any help, I appreciate

syKim

Re: [Jython-dev] Mini PEP: IgnoreMethodTag

[Stuart S. <st...@me...>]

If the dummy exception would appear in the Java source,
it might be helpful to name the Exception so that the
context of PyJava / Jython is clear, e.g.
JythonIgnoreMethodTag
(although IgnoreMethodTag might have this context embedded
by virtue of the package it will contained in... which raises the
question of which package ).  Otherwise, this seems to match
the pattern used by Cloneable more or less.



Stuart
Swerdloff


Finn Bock wrote:

> When making classes and modules it is often necessary to remove unwanted
> names from the class dict. We have used the ClassDictInit mechanisme for
> this, and it works ok when we want to clean up all methods with same
> name.
>
> I suggest we add another, finer mechanism where we can mark individual
> java methods and constructors that they should not be reflected into
> jython.
>
> PyJavaClass will look for the dummy exception "IgnoreMethodTag". Methods
> and constructors which throws this exception will be skipped and not
> inserted into the class dict.
>
> A common use would be:
>
>     public String toString() throws IgnoreMethodTag {
>         ...
>     }
>
> regards,
> finn
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] [ jython-Patches-448158 ] IgnoreMethodTag

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Finn Bock (bckfnn)
Assigned to: Nobody/Anonymous (nobody)
Summary: IgnoreMethodTag

Initial Comment:
Selected methods and contructors of the java API can 
be hidden from jython with this patch.

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

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

[Jython-dev] Mini PEP: IgnoreMethodTag

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

When making classes and modules it is often necessary to remove unwanted
names from the class dict. We have used the ClassDictInit mechanisme for
this, and it works ok when we want to clean up all methods with same
name.

I suggest we add another, finer mechanism where we can mark individual
java methods and constructors that they should not be reflected into
jython.

PyJavaClass will look for the dummy exception "IgnoreMethodTag". Methods
and constructors which throws this exception will be skipped and not
inserted into the class dict.

A common use would be:

    public String toString() throws IgnoreMethodTag {
        ...
    }

regards,
finn

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

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bryn Keller (xoltar)
>Assigned to: Finn Bock (bckfnn)
Summary: Fix NPE in PyString constructor

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

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

>Comment By: Finn Bock (bckfnn)
Date: 2001-08-05 06:44

Message:
Logged In: YES 
user_id=4201

Fixed in PyString.java: 2.47;

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

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

[Jython-dev] Including PyXML in the distribution.

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

I'm planning on including parts of the PyXML files with the jython
distribution. To solve the problem of syncronizing with the PyXML
sources I suggest that we don't include any of xml files in jython.
Instead I have added an ant task "installXML" that will copy the
selected files from a separately downloaded PyXML source distribution
into the CVS directory of Jython.

This should allow CVS users to play with and test the xml support in
jython. The downside of this approach is that we can't restore a
complete version of an older jython release only from the jython CVS.

As of 0.6.5 of PyXML the jython support consist of drv_xmlproc driver
and minidom and 4DOM.

The xml/__init__.py will be taken from CPython. This should then allow a
user to install a _xmlplus replacement module that will override the xml
support that is included with jython.

Comments from people that have actually used the python xml support will
be highly appriciated.

regards,
finn

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

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

-> JZope (or Jope?) would be great and an obvious upgrade for zope, I believe.
-> 
-> I think Jope should be an opportunity for a speed upgrade since Java is
-> considerably faster than cpython.  jpython is slow because it can not use
-> java atomic (non-object) types for int's etc.  The python spec'n would have
-> to change to make that a possibility (at least while retaining 100%
-> compatibility with cpython).

Thanks for the meaty post, first of all -- that adds to the issues that
Jeremy raised.

I should note that one can now compile Java byte code to native machine
code, via the GCJ front-end (a GCC family member).  I don't know how much
of a speedup this would give you, and, since my current app uses Swing,
which doesn't have GCJ libs yet, I've not tested it out.

On the other hand, as Jeremy Hylton pointed out, Zope uses a lot of C
extension classes.  Without some way to talk to them from Jython, you'd
have to redo an awful lot of work, and it's clear that reimplementing
them in Java would NOT lead to a speed increase ;).  This is *separate* from
all the bytecode issues...

I asked the Webware creator, Chuck Esterbrook, if Webware used any C
extension classes, and it turns out that it doesn't.  So Webware could
be a good candidate for "porting" to Jython, if people are interested in
a complete OO Web framework.

cheers,
--titus

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

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

John,
<snip>
>
>As it turns out, the new j2sdk1.4.0 is capable of Non
>blocking IO.  Once I create my medusa like interface
>wrappers i will benchmark it against the standard
>python asyncore package.  However, I need not
>implement the asyncore module in Jython (python).
>Because the interchangeability of java and Jython
>classes as well as the ease of use of the Jython API,
>I can whip it up directly in Java with little time
>penality.
>
>We will soon see...
<snip>

Just in case you need sth to fall back onto from java 1.4 (...):
http://softwaredev.earthweb.com/java/article/0,,12082_626271,00.html
This is a java replacement for select(), they call it a Multiplexor,
basically a single thread doing all the read()s and some sleep().

I hope you don't need this,
Have fun,
Ype

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

[Joseph G. <oc...@se...>]

JZope (or Jope?) would be great and an obvious upgrade for zope, I believe.

I think Jope should be an opportunity for a speed upgrade since Java is
considerably faster than cpython.  jpython is slow because it can not use
java atomic (non-object) types for int's etc.  The python spec'n would have
to change to make that a possibility (at least while retaining 100%
compatibility with cpython).

Since this post, Zope Inc. has taken control of python development though,
so they have the ability to change both zope and python now.  There has also
been some very recent discussion on ExtensionClass work that could relate to
easing the port of zope to Java.  So that could be one fewer hurdles which
is good.  It's also good since it may reflect some interest by Zope Inc. in
the direction of a Jope.

On the down side, Zope Inc. has repeatedly expressed the perception (even at
the top levels) that Java is in *competitor* to Zope.  Nonsense to me when
the two technologies dovetail so nicely, but they perceive servlets and jsp
as weak-kneed competition for zope.  (Perhaps the ExtensionClass work is an
indication of a change of heart?)

In any case, the following quoted post is the meatiest overview of the
challenges of porting to java that I've seen on the lists since becoming
interested in zope a couple of years ago.  Unfortunately, I haven't used it
for over a year, so I'm no closer to understanding than the post itself, but
you may find it useful.  I would be interested in a jope or jzope.  :-)

= Joe =

From:  Joe Grace <oc...@se...>
11/3/99 12:12 PM
Subject: Re: [Zope] Java Port
CC: "zo...@zo..." <zo...@zo...>

Awesome post.  Thanks.  And ouch.

Sounds like heavy lifting.  That bytecode stuff sounds sticky (hadn't even
heard
of that low a level of stuff before).  I still think its an obvious win, but
I can
see where it may just be way hard.

Something (for me) to strive for as I come up to speed with Zope.

Thanks for the survey Phillip,

= Joe =


"Phillip J. Eby" wrote:

> At 08:06 PM 11/2/99 -0800, Joe Grace wrote:
> >
> >Finally, on a coder side, there's been some discussion on this topic
> >before.  DC has reflected on the subject and pointed out some
> >non-trivialities of porting to Java (mainly (?) C code).  I imagine it's
> >non-trivial, but getting something running might be reasonable.
>
> Actually, no, it isn't.  The only part of Zope which might be 'reasonable'

> is the ZPublisher bit, and even it makes heavy use of reflection (see
> below).  Here are just a few of the things I'm aware of:
>
> * Reflection: Zope makes heavy use of Python internals, such as function
> metadata and examination of bytecodes used in Python expressions.  These
> are not available in JPython, and it's not even a C issue, just a Python
> implementation issue.  One reason some of these items don't exist in
> JPython, is that JPython uses Java bytecodes, not Python bytecodes.
> ZPublisher and DTML both use these reflection
>
> * ExtensionClasses: ZPublisher and DTML are the only parts of Zope that
can
> work without ExtensionClasses (and DTML performance suffers without the
> MultiMapping extension).  ExtensionClasses are C-based Python types which
> override object behaviors in ways that Python objects cannot.  This means
> that porting them to JPython means altering the JPython Java skeletons -
> which will require good understanding of JPython internals, as well as an
> *extremely* good understanding of the intent of the original C
implementation.
>
> * Persistence and synchronization: Zope object persistence and
> synchronization are implemented via ExtensionClasses, and involve further
> magic that will require very good understanding of the JPython skeletons
as
> well as the current C implementation for Zope.
>
> * Acquisition: Actually, not as difficult, compared to ExtensionClasses as

> a whole and persistence in particular, but it's still ExtensionClass based

> and probably a fair bit of work to do right.
>
> In short, if you want a "JZope", you're going to have to work mighty hard
> for it.  Or...  if Pythons 1.6 through 2.0 move the ExtensionClass
> machinery, or something like it, into the base definition of Python..  AND

> the JPython folks follow suit...  AND Digital Creations moves to the new
> "standard" extension machinery, THEN...  a JPython port might be
(somewhat)
> more "reasonable."
>
> I thought the idea was pretty cool myself a while back, until I started
> thinking about what it would actually take.  IMHO, it's too much work just

> to get one extra buzzword added to Zope's already extensive collection of
> them.  :)

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

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

> Now I'm really confused!  Some time ago (> 1 yr?) I

me too?


As it turns out, the new j2sdk1.4.0 is capable of Non
blocking IO.  Once I create my medusa like interface
wrappers i will benchmark it against the standard
python asyncore package.  However, I need not
implement the asyncore module in Jython (python). 
Because the interchangeability of java and Jython
classes as well as the ease of use of the Jython API,
I can whip it up directly in Java with little time
penality.

We will soon see...

The "jZope" project does necessarily have to be Zope,
only Zope like with little incompatibilities.  And for
this, Acquisition is a must (just about done).  The
persistence mechanism is important but not necessary
since other techniques such as 02R mappings are
available.  And as far as I know, java already has
this stuff available (enterprise objects framework),
thus porting to jZope is a piece of cake.

(and all this due to the brilliant interchangeability
of Java and Jython)

The work done here is rather important believe it or
not.  Since jZope project could easily take advantage
of all the DB connectivity software available to java.
 This team does not have to support any db
connectivity software at all and focus on the reaaly
cool stuff.


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

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

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

->   -> TB> that Zope's C code is primarily in the area of medusa, their
->   -> TB> request-handling front-end.  So, if you can figure out how to
->   -> TB> disentangle Zope from medusa, it shouldn't be too hard to
->   whip -> TB> up something that works.  -> -> There is little or no C
->   code in medusa.  A quick scan of the Zope -> source tree shows that
->   C code is used in the following places:
-> 
->   TB> Really?  Oh, because asyncore has been integrated into the
->   TB> distribution, right?  But it's not in Jython... for obvious
->   TB> reasons.
-> 
-> asyncore is implemented in Python on top of select.  I'm not sure what
-> C code you think is in there :-).

Now I'm really confused!  Some time ago (> 1 yr?) I seem to recall asyncore
being compiled on my Zope install.  I also remember that there was a separate
page (from the Python docs) explaining what asyncore was  -- this was back
in the days of 1.5.2...

Then, at the Python9 conference, someone told me that asyncore was a
really good, low-level implementation that could not easily be beat
in terms of performance.

OK, well, looking around I see nothing that 


-> 
->   -> - ExtensionClass and friends, which are used to implement ->
->   acquisition and a host of other things;
-> 
->   TB> Ahh, this I didn't know about...
-> 
->   -> - BTrees, which are used to implement catalogs aka searches; and
-> 
->   TB> Presumably this functionality could be replaced fairly easily
->   TB> with existing Java classes, no?
-> 
-> Probably not.  The BTrees are persistence objects that interact with
-> ZODB. 
-> 
->   -> - ZODB, which provides the persistence / transaction machinery.
-> 
->   TB> ZODB is (AFAIK) client/server, yes?
-> 
-> Not really.  ZODB is a transactional persistence mechanism for Python.
-> It needs to hook into the interpreter in a pretty low-level way to
-> move objects in and out of memory.  The only client-server part is
-> ZEO, which is just one option from providing storage for the state of
-> persistent objects.
-> 
->   -> TB> Also see my "Zope is Evil" page for mild commentary about the
->   -> TB> smugness of Zopatistas ;).  -> -> I'm sure you have plenty of
->   legitimate technical criticisms of Zope.  -> "Evil" doesn't suggest
->   to me what they are.  It sounds more like name -> calling to me, but
->   perhaps I'm just smug.
-> 
->   TB> ;) You should probably go read the page... Most of my criticisms
->   TB> ;are not,
->   TB> in fact, technical, but (at least wrt the state of documentation
->   TB> and the user community) were methodological.
-> 
-> I just scanned your page.  It's hard to follow all the stuff at the
-> beginning.  It seems basically polemical; there's no technical content
-> or criticism that seems worth taking time to respond to.
-> 
-> Jeremy
-> 
-> 
-> 
-> _______________________________________________
-> Jython-dev mailing list
-> Jyt...@li...
-> http://lists.sourceforge.net/lists/listinfo/jython-dev

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

[Jeremy H. <je...@zo...>]

>>>>> "TB" == Titus Brown <ti...@ca...> writes:

  -> TB> that Zope's C code is primarily in the area of medusa, their
  -> TB> request-handling front-end.  So, if you can figure out how to
  -> TB> disentangle Zope from medusa, it shouldn't be too hard to
  whip -> TB> up something that works.  -> -> There is little or no C
  code in medusa.  A quick scan of the Zope -> source tree shows that
  C code is used in the following places:

  TB> Really?  Oh, because asyncore has been integrated into the
  TB> distribution, right?  But it's not in Jython... for obvious
  TB> reasons.

asyncore is implemented in Python on top of select.  I'm not sure what
C code you think is in there :-).

  -> - ExtensionClass and friends, which are used to implement ->
  acquisition and a host of other things;

  TB> Ahh, this I didn't know about...

  -> - BTrees, which are used to implement catalogs aka searches; and

  TB> Presumably this functionality could be replaced fairly easily
  TB> with existing Java classes, no?

Probably not.  The BTrees are persistence objects that interact with
ZODB. 

  -> - ZODB, which provides the persistence / transaction machinery.

  TB> ZODB is (AFAIK) client/server, yes?

Not really.  ZODB is a transactional persistence mechanism for Python.
It needs to hook into the interpreter in a pretty low-level way to
move objects in and out of memory.  The only client-server part is
ZEO, which is just one option from providing storage for the state of
persistent objects.

  -> TB> Also see my "Zope is Evil" page for mild commentary about the
  -> TB> smugness of Zopatistas ;).  -> -> I'm sure you have plenty of
  legitimate technical criticisms of Zope.  -> "Evil" doesn't suggest
  to me what they are.  It sounds more like name -> calling to me, but
  perhaps I'm just smug.

  TB> ;) You should probably go read the page... Most of my criticisms
  TB> ;are not,
  TB> in fact, technical, but (at least wrt the state of documentation
  TB> and the user community) were methodological.

I just scanned your page.  It's hard to follow all the stuff at the
beginning.  It seems basically polemical; there's no technical content
or criticism that seems worth taking time to respond to.

Jeremy

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

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

->   TB> that Zope's C code is primarily in the area of medusa, their
->   TB> request-handling front-end.  So, if you can figure out how to
->   TB> disentangle Zope from medusa, it shouldn't be too hard to whip
->   TB> up something that works.
-> 
-> There is little or no C code in medusa.  A quick scan of the Zope
-> source tree shows that C code is used in the following places:

Really?  Oh, because asyncore has been integrated into the distribution,
right?  But it's not in Jython... for obvious reasons.

->     - ExtensionClass and friends, which are used to implement
->       acquisition and a host of other things;

Ahh, this I didn't know about...

->     - BTrees, which are used to implement catalogs aka searches; and

Presumably this functionality could be replaced fairly easily with
existing Java classes, no?

->     - ZODB, which provides the persistence / transaction machinery.

ZODB is (AFAIK) client/server, yes?

-> There is also C code in access control, document templates, and the
-> PCGI wrapper.  Zope also includes zlib and expat, which are
-> implemented in C.

Wow.  For zlib and expat, there are drop-in replacements; dunno how hard
the rest would be.

->   TB> Also see my "Zope is Evil" page for mild commentary about the
->   TB> smugness of Zopatistas ;).
-> 
-> I'm sure you have plenty of legitimate technical criticisms of Zope.
-> "Evil" doesn't suggest to me what they are.  It sounds more like name
-> calling to me, but perhaps I'm just smug.

;) You should probably go read the page... Most of my criticisms are not,
in fact, technical, but (at least wrt the state of documentation and the
user community) were methodological.

--t

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

[Jeremy H. <je...@zo...>]

>>>>> "TB" == Titus Brown <ti...@ca...> writes:

  TB> that Zope's C code is primarily in the area of medusa, their
  TB> request-handling front-end.  So, if you can figure out how to
  TB> disentangle Zope from medusa, it shouldn't be too hard to whip
  TB> up something that works.

There is little or no C code in medusa.  A quick scan of the Zope
source tree shows that C code is used in the following places:

    - ExtensionClass and friends, which are used to implement
      acquisition and a host of other things;

    - BTrees, which are used to implement catalogs aka searches; and

    - ZODB, which provides the persistence / transaction machinery.

There is also C code in access control, document templates, and the
PCGI wrapper.  Zope also includes zlib and expat, which are
implemented in C.

In other words, C code provides several crucial features to Zope that
have nothing to do with the front-end.

The recent type-class unification work aims to extend the Python code
so that some (much?) of this C code is unnecessary, but I don't know
how long it will take to see that work folded back into Jython.

  -> Isn't that what they said about the feasibility of implementing
  -> JPython, too?

I recall Guido dismissing it as impossible, too.

  TB> Also see my "Zope is Evil" page for mild commentary about the
  TB> smugness of Zopatistas ;).

I'm sure you have plenty of legitimate technical criticisms of Zope.
"Evil" doesn't suggest to me what they are.  It sounds more like name
calling to me, but perhaps I'm just smug.

Jeremy

Re: [Jython-dev] building from cvs

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

Hello Brian,

On Fri, 3 Aug 2001, Brian Parker wrote:
>
> Hi,
>
> I'm trying to build from src.  I have installed javacc2.0.  And I have
> changed the 'build.xml' to make sure this property is set:
> <property name="javaccHome" value="C:/A_temp/java_cc/javacc2.0/bin/lib"
> />
>
> Here is the output from running ant:
> <snip>
> C:\A_temp\cvs_projects\jython\jython>ant
> Buildfile: build.xml
>
> init:
>
> prepare:
>
> tree:
>
> BUILD FAILED
>
> C:\A_temp\cvs_projects\jython\jython\build.xml:45: Javacchome not set.
> </snip>
>
> I tried setting 'javacchome' as an environment variable also, to no
> avail.
>
> Any help would be greatly appreciated.
>
> Brian


try:
<property name="javaccHome2" value="C:/A_temp/java_cc/javacc2.0/bin/lib"
/>

The reason being that if you look further down the build.xml file you'll
see:

        <jjtree
            javacchome="${javaccHome2}"
            target="org/python/parser/python.jjt"
            outputdirectory="org/python/parser/"
        />


Notice the 2.

It's a bit of a glitch in the build.xml.

Cheers,
Robert

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

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

-> Interestingly, I attended the recent Washington, DC Zope/Python
-> User's Group meeting and mentioned that I'm new to both
-> Python (through Jython) and Zope.  One of the guys from
-> Digital Creations immediately piped up with "Great!  You
-> can do the Zope jython port!"  When I quizzed him on whether
-> there *was* a jython port, he smirked; they seemed to believe
-> that it was a> unnecessary and b> very hard/impossible,
-> a> because of their perception that Java is overhyped and slow
-> and b> because of the complexity of the C code behind Zope.

I would have to agree with the "slow" comment, but Zope is hardly
a prize-winning racecar either... of course, I doubt the Python
class manipulation is going to get any faster in Jython!

My understanding -- correct me if it differs from reality! -- is that
Zope's C code is primarily in the area of medusa, their request-handling
front-end.  So, if you can figure out how to disentangle Zope from medusa,
it shouldn't be too hard to whip up something that works.

And, if you can do that, let me know, too, because I set out to do
something like it a loong time ago, but within Python.  I wanted
to hook Zope up to PyWX, an embedding of Python in AOLserver,
but failed.  The frustration caused by the attempt comes through in my
Zope Is Evil page (zope-is-evil-666.idyll.org)...

-> Isn't that what they said about the feasibility of implementing
-> JPython, too?

Also see my "Zope is Evil" page for mild commentary about the smugness of
Zopatistas ;).

--titus

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

[Andrew B. <ab...@fa...>]

john coppola wrote:

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

Interestingly, I attended the recent Washington, DC Zope/Python
User's Group meeting and mentioned that I'm new to both
Python (through Jython) and Zope.  One of the guys from
Digital Creations immediately piped up with "Great!  You
can do the Zope jython port!"  When I quizzed him on whether
there *was* a jython port, he smirked; they seemed to believe
that it was a> unnecessary and b> very hard/impossible,
a> because of their perception that Java is overhyped and slow
and b> because of the complexity of the C code behind Zope.

Isn't that what they said about the feasibility of implementing
JPython, too?

Andy Boyko  ab...@fa...