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

Thread view

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

>>>>> "Finn" == Finn Bock <bckfnn@...> writes:
Finn> How about returning "mtime / 1000.0" as a float number. This is
Finn> already the case for CPython on macs. If any libraries fail to
Finn> handle a float it is surely a bug in the library.
I think that would be the most clean solution. It _must_ return a
value which is compatible with the time library, and that is
seconds. So time/1000.0 would be a very clean solution in my opinion.
Karsten