Jython

We got this bug report:

>Details: jython-2.0,  Sun JDK-1.3, Linux
>
>The os.stat differs between cpython and jython. One can expect, that not
>all values is available in jython, but the time fields is 1000 times larger
>in jython that in cpython which makes the time library fail when operating
>on the values.
>
>Here is an example in jython and cpython for comarrison:
>
>Jython:
>>>> import os
>>>> os.stat('jakarte-test')
>(0, 0, 0, 0, 0, 0, 15761L, 980410501000L, 980410501000L, 0)
>
>Python:
>>>> import os
>>>> os.stat('jakarte-test')
>(33204, 1217412, 3, 1, 2115, 1000, 15761, 980410501, 980410501,
>980410501)
>
>
>Also, the size is a long, while Python return an int.
>
>For detailed info, follow this link:
>http://sourceforge.net/bugs/?func=detailbug&bug_id=130021&group_id=12867

The values from os.stat() is really poorly documented

   http://www.python.org/doc/lib/os-file-dir.html#l2h-968

, but I agree that the returning values which is different from cpython
is unfortunate. But what to do?

I'm sure most unix users feel fine with a simple "int(mtime / 1000)"
hack, because the file time resolution is a second on (all?) unices. On
WinNT this would be an actual loss of information since WinNT have
millisecond file time resolution.

How about returning "mtime / 1000.0" as a float number. This is already
the case for CPython on macs. If any libraries fail to handle a float it
is surely a bug in the library.

Comments?

regards,
finn

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&group_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

Patch #103419 has been updated. 

Project: jython
Category: None
Status: Open
Submitted by: bckfnn
Assigned to : nobody
Summary: Reworked coercion model

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

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

Hi, when I click on the download class I get page not found....


I am currently a Java developer and I am looking for a good scripting
language why jython as opposed to perl etc. Please advise

tia 

ed ;)

[brian zimmer]

>As some might be aware, CPython is getting ready to release version 2.1 
>with a number of new features:
>
>http://www.amk.ca/python/2.1/
>
>I was wondering if anyone has started adding these to Jython?  

I'm currently working on the coercion model and rich comparison.

>If not I'd like to offer assistance in getting Jython up to speed.

I have added the major new features as task to the task manager on
sourceforge. If anyone wants to tackle a task or fix a bug they can post
their intention here (to avoid duplicate work). Patches can be posted to
the patch manager.

http://sourceforge.net/pm/task.php?group_project_id=6960&group_id=12867&func=browse
http://sourceforge.net/patch/?group_id=12867

Developer rights are granted to patch writers with a proven history of
atleast 1 non-trivial patch.

In addition to the tasks on the tasklist, I hope these tests from
CPython-2.1 will succeed by the time Jython-2.1 is released.


import regrtest
tests = [
    '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_contains',
    'test_cookie',
    'test_copy_reg',
    'test_cpickle',
#   'test_crypt',
    'test_dospath',
    'test_dumbdbm',
    'test_exceptions',
    'test_extcall',
    'test_file',
    'test_format',
    'test_funcattrs',
    'test_getopt',
    'test_grammar',
    'test_gzip',
    'test_hash',
    'test_import',
    'test_long',
    'test_mailbox',
    'test_math',
    'test_md5',
    'test_mimetools',
    'test_MimeWriter',
    'test_ntpath',
    'test_operations',
    'test_operator',
    'test_pickle',
    'test_pkg',
    'test_posixpath',
    'test_pow',
    'test_re',
    'test_rfc822',
    'test_richcmp',
    '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_xmllib',
    'test_xreadline',
    'test_zipfile',
    'test_zlib',
]
regrtest.main(tests)

regards,
finn

SSBhbSB0cnlpbmcgdG8gaW5zdGFsbCBKeXRob24tMi4wLCBidXQgaXQgaXMgc2hvd25pbmcg
dGhpcyBlcnJvcg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV4Y2VwdGlvbiBp
biB0aHJlYWQgIm1haW4iDQpqYXZhLmxhbmcuTm9DbGFzc0RlZkZvdW5kRXJyb3I6IC90bXAv
anl0aG9uLTIwDQoNCkkgYW0gdHJ5aW5nIHRvIGluc3RhbGwgb24gSFAtVVgxMS4wIE9TICkg
IGFuZCAgIGphdmExLjINCiAgICAgICAgV2hhdCBzaGFsbCBJIGRvDQoNClJlZ2FyZHMNCg==

Hi.

The python 2.1 features (quoted from its NEWS):

- Two changes to from...import:

1) "from M import X" now works even if M is not a real module; it's
   basically a getattr() operation with AttributeError exceptions
   changed into ImportError.

2) "from M import *" now looks for M.__all__ to decide which names to
   import; if M.__all__ doesn't exist, it uses M.__dict__.keys() but
   filters out names starting with '_' as before.  Whether or not
   __all__ exists, there's no restriction on the type of M.

are already there in jython.

I will check if there is a regression test for that in any case, in
order to check for "details".

PS: in jython there is a more general old jpython bug related to __all__ (for
packages too), I will fix it as soon as possible.

Hi Ype,
thanks for your detailed answer
showing the background of the problem.
Meanwhile I helped myself using the
Java Telnet Application (JTA) within Jython:
http://www.mud.de/se/jta/
You can use JTA for Telnet connections
and SSH (with Cryptix), too.  
Highly recommandable!

best regards,
Markus

----- Original Message ----- 
From: "Ype Kingma" <ykingma@...>
To: "Markus Wenzel" <Wenzel@...>; <jython-dev@...>
Sent: Tuesday, January 23, 2001 8:58 PM
Subject: Re: [Jython-dev] (no subject)


> >Hello,
> >
> >where can I find module select.
> >It's not in [My-Jython2.0-Dir]/Lib.
> >I got an import error if I try to
> >import this module.
> >(I.E. it's used by module telnetlib).
> >I have no problem with other Libs.
> 
> A few days ago I checked briefly on the sockets that
> Java makes available and this is what I found:
> 
> The 'native' Java lib does not provide a select function,
> so Jython cannot make use of it. The sockets that are there
> only a allow to check whether sockets are ready for reading,
> ie. you can get to the inputstream of a socket and ask
> for the nr. of bytes it has available. However you can't
> ask the socket's outputstream for the nr. of bytes it hasn't
> written yet, you can only flush the outputstream.
> Also there is no out of band data in Java, and for
> exceptional things (like TCP/IP errors) happening to an
> inputstream, you would have to catch the corresponding
> exception from the socket first.
> Read timeouts are there, and so is the TCP no delay option,
> as well as a shutdown and lingering on close. Non blocking
> reads can be done by using a very short time out.
> You can't do non blocking writes IIRC.
> 
> I still hope I didn't look close enough, though.
> 
> 
> Regards,
> Ype
>