[Jython-dev] Re: [JPython] New Coercion Model

[Brad B. <bbu...@uc...>]

Hi,

On the topic of coercion, currently (correct me if I'm wrong) when a java
numeric primitive (it, double, etc.) is accessed from jython code a
conversion takes place from the native java type to a PyNumber object.
Now, since Python offers many features (slicing, operator overloading,
function pointers, etc.)  that are extremely useful from a numerical
computing standpoint (hence the success of NumPy) and Java offers excellent
and robust Matrix libraries, 2D & 3D graphics, excellent gui, an advanced
imaging package -- and so on -- Jython holds a lot of potential in the
numerical computing arena (see ViSad, a scientific visualization package
which has incorporated JPython as a scripting feature).  That said, the
current treatment of java primitives as PyObjects is a barrier to jython
emerging as a (fast) platform for numerical computing.

Is there any way that java primitives could be accessed "as-is" from within
Jython?

Note that Numerical Python suffers from requiring a rag-bag of supplementary
tools for graphing, imaging, etc. -- which are not generally
cross-platform --  while Java offers all these things in existing libraries
either put out by Sun or downloadable off the web and, of course, fully
cross-platform.  So, to me, Jython has vastly more potential as a numerical
computing language than Python proper.  Moreover, proprietary computing
environments like Matlab, Mathematica, and S-Plus are all scrambling to
provide "java links" into their own languages.  None of these links will
ever be as good as the Jython-Java connection, nor will those scripting
languages ever be as good as Python for general computing.  (See
www.omegahat.org  for a project that is trying to integrate the S language
and java at the cost of considerable complexity).

Brad Buchsbaum


----- Original Message -----
From: "Finn Bock" <bc...@wo...>
To: <jyt...@li...>
Cc: <jyt...@li...>; <jpy...@py...>
Sent: Thursday, January 25, 2001 12:06 PM
Subject: [JPython] New Coercion Model


> Hi,
>
> I have been working on a change to the coercion model that matches the
> change that CPython 2.1 have introduced. The change only affect the
> implementation of PyObject and its subclasses. It have no effect on
> python objects that define __coerce__ or any of the other __XXX__ number
> methods.
>
> The effect of the change is that the __XXX__ number methods can receive
> argument(s) that aren't of the same type as itself. It is then the (new)
> responsibility of each __XXX__ method to check its argument and return
> Py.NotImplemented if the operation cannot be done with such an argument.
> As a result the __coerce_ex__ is no longer called.
>
> The patch, as I have it now, does not supply a backward compatiblity
> mode and that is subject on which I'm seeking feedback:
>
> I would like to hear from you if you have coded your own PyObject
> subclass which override any of the number methods. Take a look at the
> "new" way that this can be coded (example below is taken from PyFloat)
> and send me your feedback and comments.
>
> Adding backward compatibility is ofcourse possible, but it would mean we
> have to carry around some kind of flag around (NEW_STYLE_NUMBER) and I
> would rather avoid that if possible. I would also like to get rid of the
> currect coercion code because it complicated and there are bugs in it.
>
> The benefit of the new coercion model is improved speed when mixing
> object types in operations because it isn't necessary to create a
> temporary object and improved control from an extension type because it
> now gets the unmodified arguments pass to it.
>
> The full patch can be found here:
>
>
http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103419&grou
p_id=12867
>
> A few example methods taken from PyFloat. It showns how the numeric
> methods can be implemented under the new coercion mode:
>
>
>     public PyObject __add__(PyObject right) {
>         if (!canCoerce(right))
>             return Py.NotImplemented;
>         double rightv = coerce(right);
>         return new PyFloat(value + rightv);
>     }
>
>     public PyObject __radd__(PyObject left) {
>         return __add__(left);
>     }
>
>     public PyObject __sub__(PyObject right) {
>         if (!canCoerce(right))
>             return Py.NotImplemented;
>         double rightv = coerce(right);
>         return new PyFloat(value - rightv);
>     }
>
>     public PyObject __rsub__(PyObject left) {
>         if (!canCoerce(left))
>             return Py.NotImplemented;
>         double leftv = coerce(left);
>         return new PyFloat(leftv - value);
>     }
>
>     private static final boolean canCoerce(PyObject other) {
>         return other instanceof PyFloat || other instanceof PyInteger ||
>             other instanceof PyLong;
>     }
>
>     private static final double coerce(PyObject other) {
>         if (other instanceof PyFloat)
>             return ((PyFloat) other).value;
>         else if (other instanceof PyInteger)
>             return ((PyInteger) other).getValue();
>         else if (other instanceof PyLong)
>             return ((PyLong) other).doubleValue();
>         else
>             throw Py.TypeError("xxx");
>     }
>
>
> regards,
> finn
>
> _______________________________________________
> JPython-Interest maillist  -  JPy...@py...
> http://mail.python.org/mailman/listinfo/jpython-interest
>