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

[Jython-dev] AArch64 support

[Andrew H. <ap...@re...>]

I've been trying to install Jython and not having much luck.

The symptom is that I get a fail when installing:

  File "/home/aph/jython2.7.0/Lib/pwd.py", line 60, in getpwuid
    return struct_passwd(entry)
  File "/home/aph/jython2.7.0/Lib/pwd.py", line 36, in __new__
    pwd = (newStringOrUnicode(pwd.loginName), newStringOrUnicode(pwd.password), int(pwd.UID),
NotImplementedError: passwd.pw_passwd unimplemented

I think I've tracked my problem down to an obsolete jffi which doesn't
support AArch64.  Do I need to do anything more than simply copy
jffi-i386-Linux.jar into extlibs?  is that a reasonable guess at the
failure?

BTW, I am the lead of the AArch64 OpenJDK port.  If you want me
to test on AArch64, I can do that.

Andrew.

Re: [Jython-dev] Support for sys._current_frames

[Stefan R. <Ste...@gm...>]

> Your elements array should be twice as long, I think?
Obviously it should ;)

Agreed on all points. I just tested the implementation and observed that
an entry in globalThreadStates yields a null-PyFrame. How should we deal
with that?

a) Is it a bug and we should investigate how it can be null and solve it?
b) set the frame to None in result of _current_frames
c) skip such elements and let _current_frames only return a reduced dict?

@Fabio regarding b), would PyDev be robust against None-values here?

Despite this, the result looks rather much like in CPython.


> Gesendet: Mittwoch, 29. März 2017 um 22:04 Uhr
> Von: "Jeff Allen" <ja...@fa...>
> An: jyt...@li...
> Betreff: Re: [Jython-dev] Support for sys._current_frames
>
> This seems to be a faithful equivalent to the CPython implementation. 
> That is wrapped in a synchronisation construct, but globalThreadStates 
> is of a thread-safe class, I see. However, as the number of threads 
> might change between the call to size() and the call to toArray(), I 
> think it would be better to let toArray() always allocate the array 
> (i.e. give it a zero-length prototype).
> 
> Your elements array should be twice as long, I think?
> 
> The way we manage ThreadState and interpreters leaves me uneasy, but 
> that's not a criticism against this proposal, except for the risk of 
> change when the penny finally drops.
> 
> Oh, and thanks to Fabio for continuing to support Jython in PyDev.
> 
> Jeff Allen
> 
> On 29/03/2017 17:30, Stefan Richthofer wrote:
> > I suggest this could be implemented in ThreadStateMapping like this:
> > (on top of that an implementation in PySystemState is straight forward)
> >     public static PyObject _current_frames() {
> >         @SuppressWarnings("unchecked")
> >         Map.Entry<Thread, ThreadState>[] entries = new 
> > Map.Entry[globalThreadStates.size()];
> >         entries = globalThreadStates.entrySet().toArray(entries);
> >         PyObject elements[] = new PyObject[entries.length];
> >         int pos = 0;
> >         for (Map.Entry<Thread, ThreadState> entry: entries) {
> >             elements[pos++] = Py.newInteger(entry.getKey().getId());
> >             elements[pos++] = entry.getValue().frame;
> >         }
> >         return new PyDictionary(elements);
> >     }
> > Opinions?
> > -Stefan
> > *Gesendet:* Mittwoch, 29. März 2017 um 17:30 Uhr
> > *Von:* "Fabio Zadrozny" <fa...@gm...>
> > *An:* "Jython Developers" <jyt...@li...>
> > *Betreff:* [Jython-dev] Support for sys._current_frames
> > Hi Jython devs,
> > I've just updated the PyDev debugger to drop support for older Python 
> > versions and it seems I ended up breaking debugging in the current 
> > Jython version because of it...
> > The issue is that PyDev now requires sys._current_frames to be 
> > implemented by the interpreter (available since Python 2.5), but it 
> > seems this is not available for Jython -- this is needed so that the 
> > debugger can be faster (i.e.: it runs with untraced frames until some 
> > breakpoint is actually added -- at that point it gets the current 
> > frames and sets the tracing in them).
> > So, I'd like to check how feasible it'd be to have this support in Jython.
> > Thanks,
> > Fabio
> > ------------------------------------------------------------------------------ 
> > Check out the vibrant tech community on one of the world's most 
> > engaging tech sites, Slashdot.org! 
> > http://sdm.link/slashdot_______________________________________________ 
> > Jython-dev mailing list Jyt...@li... 
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> > _______________________________________________
> > Jython-dev mailing list
> > Jyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Support for sys._current_frames

[Jeff A. <ja...@fa...>]

This seems to be a faithful equivalent to the CPython implementation. 
That is wrapped in a synchronisation construct, but globalThreadStates 
is of a thread-safe class, I see. However, as the number of threads 
might change between the call to size() and the call to toArray(), I 
think it would be better to let toArray() always allocate the array 
(i.e. give it a zero-length prototype).

Your elements array should be twice as long, I think?

The way we manage ThreadState and interpreters leaves me uneasy, but 
that's not a criticism against this proposal, except for the risk of 
change when the penny finally drops.

Oh, and thanks to Fabio for continuing to support Jython in PyDev.

Jeff Allen

On 29/03/2017 17:30, Stefan Richthofer wrote:
> I suggest this could be implemented in ThreadStateMapping like this:
> (on top of that an implementation in PySystemState is straight forward)
>     public static PyObject _current_frames() {
>         @SuppressWarnings("unchecked")
>         Map.Entry<Thread, ThreadState>[] entries = new 
> Map.Entry[globalThreadStates.size()];
>         entries = globalThreadStates.entrySet().toArray(entries);
>         PyObject elements[] = new PyObject[entries.length];
>         int pos = 0;
>         for (Map.Entry<Thread, ThreadState> entry: entries) {
>             elements[pos++] = Py.newInteger(entry.getKey().getId());
>             elements[pos++] = entry.getValue().frame;
>         }
>         return new PyDictionary(elements);
>     }
> Opinions?
> -Stefan
> *Gesendet:* Mittwoch, 29. März 2017 um 17:30 Uhr
> *Von:* "Fabio Zadrozny" <fa...@gm...>
> *An:* "Jython Developers" <jyt...@li...>
> *Betreff:* [Jython-dev] Support for sys._current_frames
> Hi Jython devs,
> I've just updated the PyDev debugger to drop support for older Python 
> versions and it seems I ended up breaking debugging in the current 
> Jython version because of it...
> The issue is that PyDev now requires sys._current_frames to be 
> implemented by the interpreter (available since Python 2.5), but it 
> seems this is not available for Jython -- this is needed so that the 
> debugger can be faster (i.e.: it runs with untraced frames until some 
> breakpoint is actually added -- at that point it gets the current 
> frames and sets the tracing in them).
> So, I'd like to check how feasible it'd be to have this support in Jython.
> Thanks,
> Fabio
> ------------------------------------------------------------------------------ 
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot_______________________________________________ 
> Jython-dev mailing list Jyt...@li... 
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] Support for sys._current_frames

[Stefan R. <Ste...@gm...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>I suggest this could be implemented in ThreadStateMapping like this:</div>

<div>(on top of that an implementation in PySystemState is straight forward)</div>

<div>&nbsp;</div>

<div>&nbsp;&nbsp;&nbsp; public static PyObject _current_frames() {<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @SuppressWarnings(&quot;unchecked&quot;)<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Map.Entry&lt;Thread, ThreadState&gt;[] entries = new Map.Entry[globalThreadStates.size()];<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; entries = globalThreadStates.entrySet().toArray(entries);<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PyObject elements[] = new PyObject[entries.length];<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int pos = 0;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for (Map.Entry&lt;Thread, ThreadState&gt; entry: entries) {<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elements[pos++] = Py.newInteger(entry.getKey().getId());<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elements[pos++] = entry.getValue().frame;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return new PyDictionary(elements);<br/>
&nbsp;&nbsp;&nbsp; }</div>

<div>&nbsp;</div>

<div>Opinions?</div>

<div>&nbsp;</div>

<div>-Stefan</div>

<div>&nbsp;
<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b>&nbsp;Mittwoch, 29. M&auml;rz 2017 um 17:30 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Fabio Zadrozny&quot; &lt;fa...@gm...&gt;<br/>
<b>An:</b>&nbsp;&quot;Jython Developers&quot; &lt;jyt...@li...&gt;<br/>
<b>Betreff:</b>&nbsp;[Jython-dev] Support for sys._current_frames</div>

<div>
<div>
<div class="gmail_default" style="color: rgb(0,0,0);">Hi Jython devs,</div>

<div class="gmail_default" style="color: rgb(0,0,0);">&nbsp;</div>

<div class="gmail_default" style="color: rgb(0,0,0);">I&#39;ve just updated the PyDev debugger to drop support for older Python versions and it seems I ended up breaking debugging in the current Jython version because of it...</div>

<div class="gmail_default" style="color: rgb(0,0,0);">&nbsp;</div>

<div class="gmail_default" style="color: rgb(0,0,0);">The issue is that PyDev now requires sys._current_frames to be implemented by the interpreter (available since Python 2.5), but it seems this is not available for Jython -- this is needed so that the debugger can be faster (i.e.: it runs with untraced frames until some breakpoint is actually added -- at that point it gets the current frames and sets the tracing in them).</div>

<div class="gmail_default" style="color: rgb(0,0,0);">&nbsp;</div>

<div class="gmail_default" style="color: rgb(0,0,0);">So, I&#39;d like to check how feasible it&#39;d be to have this support in Jython.</div>

<div class="gmail_default" style="color: rgb(0,0,0);">&nbsp;</div>

<div class="gmail_default" style="color: rgb(0,0,0);">Thanks,</div>

<div class="gmail_default" style="color: rgb(0,0,0);">&nbsp;</div>

<div class="gmail_default" style="color: rgb(0,0,0);">Fabio</div>
</div>
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world&#39;s most engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot_______________________________________________" target="_blank">http://sdm.link/slashdot_______________________________________________</a> Jython-dev mailing list Jyt...@li... <a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a></div>
</div>
</div>
</div></div></body></html>

[Jython-dev] Support for sys._current_frames

[Fabio Z. <fa...@gm...>]

Hi Jython devs,

I've just updated the PyDev debugger to drop support for older Python
versions and it seems I ended up breaking debugging in the current Jython
version because of it...

The issue is that PyDev now requires sys._current_frames to be implemented
by the interpreter (available since Python 2.5), but it seems this is not
available for Jython -- this is needed so that the debugger can be faster
(i.e.: it runs with untraced frames until some breakpoint is actually added
-- at that point it gets the current frames and sets the tracing in them).

So, I'd like to check how feasible it'd be to have this support in Jython.

Thanks,

Fabio

[Jython-dev] Fwd: Re: JDK 9 EA Build 162 is available on java.net

[dalibor t. <dal...@or...>]

Forwarding to jython-dev now that I'm subscribed.

cheers,
dalibor topic


-------- Forwarded Message --------
Subject: Re: [Jython-dev] JDK 9 EA Build 162 is available on java.net
Date: Mon, 27 Mar 2017 16:32:58 +0200
From: dalibor topic <dal...@or...>
Organization: Oracle Corporation
To: Jeff Allen <ja...@fa...>, Rory O'Donnell 
<ror...@or...>, Alan Kennedy <jyt...@xh...>, Abdul 
Kolarkunnu <abd...@or...>
CC: jyt...@li...

Hi Jeff,

thank you for testing Jython with JDK 9.

Based on the description in the netty issue you linked to, it seems that 
this particular issue has been fixed in netty 4.1.8, which was released 
on January 30th, so my suggestion would be to consider upgrading netty 
in Jython to 4.1.8 or a more recent version. For the latest status, 
please see https://twitter.com/normanmaurer/status/846231880575979520 .

Regarding deprecation warnings during compilation, I'd suggest taking a 
look at JEP 277 in general : http://openjdk.java.net/jeps/277 and 
https://bugs.openjdk.java.net/browse/JDK-8145468 in particular regarding 
deprecation of boxed primitive constructors. In addition, JDK 9 comes 
with a new tool called jdeprscan, as documented at 
https://docs.oracle.com/javase/9/tools/jdeprscan.htm#JSWOR-GUID-2B7588B0-92DB-4A88-88D4-24D183660A62 
, which can be informative to run over your or third party JAR files, in 
order to detect usage of deprecated APIs without having to rebuild the 
source code.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

Re: [Jython-dev] JDK 9 EA Build 162 is available on java.net

[Jeff A. <ja...@fa...>]

I tried Jython compiled on 7, run on 9, using the Windows 64-bit JDK.

The most obvious problem is with Netty class-loading. The effect is very 
close to this: https://github.com/netty/netty/issues/6246, so it seems 
like a recurring one for them, maybe related to security management and 
the class path. I haven't delved further. "import socket" is the easiest 
way to trigger it, and it occurs as a result of  "from io.netty.buffer 
import PooledByteBufAllocator" in _socket.py.

When I build on Java 9, I get non-fatal error messages from ANTLR that I 
think are the same as on Java 8. And then a lot of deprecation warnings, 
including Class.getInstance(), and wrapper type constructors e.g. 
Integer(int). Hard to say if there are runtime problems as the Netty one 
stops us running the regression test.

Jeff Allen

On 24/03/2017 10:41, Rory O'Donnell wrote:
>
> Hi Alan,
>
> *JDK 9 Early Access* b162 <https://jdk9.java.net/download/>  is 
> available on java.net, summary of  changes are listed here 
> <http://download.java.net/java/jdk9/changes/jdk-9+162.html>.
>
> There is one fix for a bug reported by Open Source projects since the 
> last availability email  :
>
>   * b161 - JDK 8176265 Method overload resolution on a covariant base
>     type doesn't work in 9
>
> Other change that maybe of interest:
>
>   * b162 - JDK 8176503 security-libs Disable SHA-1 TLS Server Certificates
>
>
> *Better tools for adjusting to strong encapsulation -* please read 
> Mark Reinhold's email on this topic [1]
> *
> * *Quality Outreach Report for March 2017 *is available [2], many 
> thanks for your continued support
> and welcome to the new projects!
>
> ***Schedule - **JDK 9 Rampdown Phase 2*: Proposal accepted [3].
> The overall goal of this process is to ensure that we fix just the 
> bugs that must be fixed in order to ensure a successful release.
>
> Oracle's JRE and JDK Cryptographic Roadmap has been updated since last 
> availability email [4]
>
> Rgds,Rory
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
> [2] 
> https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2017
> [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005689.html
> [4] https://www.java.com/en/jre-jdk-cryptoroadmap.html
>
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2017-03-17 - 2017-03-24)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     313 ( +2)
  closed  2280 ( +1)
  total   2593 ( +3)

Open issues with patches: 29   


Issues opened (3)
=================

#2572: Network-related tests failing on build bots
http://bugs.jython.org/issue2572  opened by jeff.allen

#2573: test_weakref intermittent test failure on linux
http://bugs.jython.org/issue2573  opened by jamesmudd

#2574: test_tarfile failed during CI build
http://bugs.jython.org/issue2574  opened by jamesmudd



Most recent 15 issues with no replies (15)
==========================================

#2574: test_tarfile failed during CI build
http://bugs.jython.org/issue2574

#2567: System state lost during JSR-223 initialisation
http://bugs.jython.org/issue2567

#2562: Windows: OSError: unlink(): an unknown error occurred
http://bugs.jython.org/issue2562

#2543: broken links for mailing list website
http://bugs.jython.org/issue2543

#2540: settrace doesn't notice "with" statements
http://bugs.jython.org/issue2540

#2531: Support SNI for SSL/TLS server sockets
http://bugs.jython.org/issue2531

#2525: Jython incorrectly buffers file pipe output with Subprocess(co
http://bugs.jython.org/issue2525

#2520: Jython does NOT support socket.listen(0) for accepting only on
http://bugs.jython.org/issue2520

#2512: Values in built-in modules's __dict__ are “<reflected field 
http://bugs.jython.org/issue2512

#2510: TypeError when monkey-patching time.time with an unbound funct
http://bugs.jython.org/issue2510

#2507: Run "invokeFunction" in a thread does not inherit the "ScriptC
http://bugs.jython.org/issue2507

#2494: Support for pydoc_data
http://bugs.jython.org/issue2494

#2484: Codec encodings can exhaust permgen
http://bugs.jython.org/issue2484

#2482: Publish U.S. ECCN for Jython
http://bugs.jython.org/issue2482

#2422: test_classpathimporter fauls on Linux
http://bugs.jython.org/issue2422



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2565: test_jy_internal deadlock on Windows
http://bugs.jython.org/issue2565

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embedd other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1866: Parser does not have mismatch token error messages caught by B
http://bugs.jython.org/issue1866

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842



Issues closed (1)
=================

#2399: regrtest failures related to sort() on Java 8
http://bugs.jython.org/issue2399  closed by jeff.allen

[Jython-dev] JDK 9 EA Build 162 is available on java.net

[Rory O'D. <ror...@or...>]

Hi Alan,

*JDK 9 Early Access* b162 <https://jdk9.java.net/download/>  is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/java/jdk9/changes/jdk-9+162.html>.

There is one fix for a bug reported by Open Source projects since the 
last availability email  :

  * b161 - JDK 8176265 Method overload resolution on a covariant base
    type doesn't work in 9

Other change that maybe of interest:

  * b162 - JDK 8176503 security-libs Disable SHA-1 TLS Server Certificates


*Better tools for adjusting to strong encapsulation -* please read Mark 
Reinhold's email on this topic [1]
*
* *Quality Outreach Report for March 2017 *is available [2], many thanks 
for your continued support
and welcome to the new projects!

***Schedule - **JDK 9 Rampdown Phase 2*: Proposal accepted [3].
The overall goal of this process is to ensure that we fix just the bugs 
that must be fixed in order to ensure a successful release.

Oracle's JRE and JDK Cryptographic Roadmap has been updated since last 
availability email [4]

Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
[2] 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2017
[3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005689.html
[4] https://www.java.com/en/jre-jdk-cryptoroadmap.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: [Jython-dev] Failing tests on GitHub

[Jeff A. <ja...@fa...>]

Update: all three Travis tests green now -- a great joint effort! Not 
sure what fixed the openjdk7 core dump.

https://travis-ci.org/jythontools/jython/builds/213754331

I assume someone has disabled the Circle CI tests to work on them?

Jeff Allen

On 20/03/2017 07:31, Jeff Allen wrote:
> I have managed to achieve two green bots. So we have a canary in some
> parts of the mine.
>
> All three Circle bots appear to run exactly the same JVM. Presumably the
> identical configuration is a mistake. (I was suspicious of this, so I
> added a tell to regrtest.py.) Yet one out of three tests passes by chance:
>
> CircleCI 0: (fail test_gc)
>        [exec] == 2.7.1rc1 (, Mar 20 2017, 00:16:00)
>        [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
>        [exec] == platform: java1.7.0_95
>        [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
>        [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
> CircleCI 1: (pass)
>        [exec] == 2.7.1rc1 (, Mar 20 2017, 00:16:00)
>        [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
>        [exec] == platform: java1.7.0_95
>        [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
>        [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
> CircleCI 2: (fail test_gc)
>        [exec] == 2.7.1rc1 (, Mar 20 2017, 00:17:20)
>        [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
>        [exec] == platform: java1.7.0_95
>        [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
>        [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
>
> Travis is configured to work with 3 genuinely different JVMs:
>
> Travis 1: (pass)
>        [exec] == 2.7.1rc1 (, Mar 20 2017, 00:17:49)
>        [exec] == [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)]
>        [exec] == platform: java1.7.0_80
>        [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
>        [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
> Travis 2: (fail test_builtin with machine stack dump)
>        [exec] == 2.7.1rc1 (, Mar 20 2017, 00:17:48)
>        [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
>        [exec] == platform: java1.7.0_121
>        [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
>        [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
> Travis 3: (fail test_sort)
>        [exec] == 2.7.1rc1 (, Mar 20 2017, 00:18:59)
>        [exec] == [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)]
>        [exec] == platform: java1.8.0_92
>        [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
>        [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
>
> I left test_sort enabled because a fix seemed imminent. However, if I
> were wholly consistent with what I preach here, I'd have made it an
> expected failure in regrtest.py.
>
> Jeff
>
> Jeff Allen
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Re: [Jython-dev] Failing tests on GitHub

[Jeff A. <ja...@fa...>]

I have managed to achieve two green bots. So we have a canary in some 
parts of the mine.

All three Circle bots appear to run exactly the same JVM. Presumably the 
identical configuration is a mistake. (I was suspicious of this, so I 
added a tell to regrtest.py.) Yet one out of three tests passes by chance:

CircleCI 0: (fail test_gc)
      [exec] == 2.7.1rc1 (, Mar 20 2017, 00:16:00)
      [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
      [exec] == platform: java1.7.0_95
      [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
      [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
CircleCI 1: (pass)
      [exec] == 2.7.1rc1 (, Mar 20 2017, 00:16:00)
      [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
      [exec] == platform: java1.7.0_95
      [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
      [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
CircleCI 2: (fail test_gc)
      [exec] == 2.7.1rc1 (, Mar 20 2017, 00:17:20)
      [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
      [exec] == platform: java1.7.0_95
      [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
      [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)

Travis is configured to work with 3 genuinely different JVMs:

Travis 1: (pass)
      [exec] == 2.7.1rc1 (, Mar 20 2017, 00:17:49)
      [exec] == [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)]
      [exec] == platform: java1.7.0_80
      [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
      [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
Travis 2: (fail test_builtin with machine stack dump)
      [exec] == 2.7.1rc1 (, Mar 20 2017, 00:17:48)
      [exec] == [OpenJDK 64-Bit Server VM (Oracle Corporation)]
      [exec] == platform: java1.7.0_121
      [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
      [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)
Travis 3: (fail test_sort)
      [exec] == 2.7.1rc1 (, Mar 20 2017, 00:18:59)
      [exec] == [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)]
      [exec] == platform: java1.8.0_92
      [exec] == encodings: stdin=UTF-8, stdout=UTF-8, FS=None
      [exec] == locale: default=('en_US', 'UTF-8'), actual=(None, None)

I left test_sort enabled because a fix seemed imminent. However, if I 
were wholly consistent with what I preach here, I'd have made it an 
expected failure in regrtest.py.

Jeff

Jeff Allen

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2017-03-10 - 2017-03-17)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     311 ( +5)
  closed  2279 ( +0)
  total   2590 ( +5)

Open issues with patches: 29   


Issues opened (5)
=================

#2567: System state lost during JSR-223 initialisation
http://bugs.jython.org/issue2567  opened by jeff.allen

#2568: test_threading intermittent failure
http://bugs.jython.org/issue2568  opened by jamesmudd

#2569: jython launcher fails on Windows if JAVA_HOME is set
http://bugs.jython.org/issue2569  opened by jamesmudd

#2570: Wrong shebang set for OS X installation of Jython
http://bugs.jython.org/issue2570  opened by zyasoft

#2571: Error handling in test_codecencodings_tw fails on Java 8
http://bugs.jython.org/issue2571  opened by jeff.allen



Most recent 15 issues with no replies (15)
==========================================

#2567: System state lost during JSR-223 initialisation
http://bugs.jython.org/issue2567

#2562: Windows: OSError: unlink(): an unknown error occurred
http://bugs.jython.org/issue2562

#2543: broken links for mailing list website
http://bugs.jython.org/issue2543

#2540: settrace doesn't notice "with" statements
http://bugs.jython.org/issue2540

#2531: Support SNI for SSL/TLS server sockets
http://bugs.jython.org/issue2531

#2525: Jython incorrectly buffers file pipe output with Subprocess(co
http://bugs.jython.org/issue2525

#2520: Jython does NOT support socket.listen(0) for accepting only on
http://bugs.jython.org/issue2520

#2512: Values in built-in modules's __dict__ are “<reflected field 
http://bugs.jython.org/issue2512

#2510: TypeError when monkey-patching time.time with an unbound funct
http://bugs.jython.org/issue2510

#2507: Run "invokeFunction" in a thread does not inherit the "ScriptC
http://bugs.jython.org/issue2507

#2494: Support for pydoc_data
http://bugs.jython.org/issue2494

#2484: Codec encodings can exhaust permgen
http://bugs.jython.org/issue2484

#2482: Publish U.S. ECCN for Jython
http://bugs.jython.org/issue2482

#2422: test_classpathimporter fauls on Linux
http://bugs.jython.org/issue2422

#2418: test_chdir subprocess tests fail on Windows
http://bugs.jython.org/issue2418



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2565: test_jy_internal deadlock on Windows
http://bugs.jython.org/issue2565

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embedd other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1866: Parser does not have mismatch token error messages caught by B
http://bugs.jython.org/issue1866

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842



Top 10 most discussed issues (2)
================================

#2554: regrtest failures on Windows
http://bugs.jython.org/issue2554   4 msgs

#2568: test_threading intermittent failure
http://bugs.jython.org/issue2568   3 msgs

Re: [Jython-dev] Failing tests on GitHub

[Jeff A. <ja...@fa...>]

Yes, it was misleading to put test_sort in the same list. It fails for 
Java 8, everywhere AFAIK (http://bugs.jython.org/issue2399), best dealt 
with in regrtest somehow I suppose.

With test_socket test_sort test_ssl we could exclude them from the 
custom ant regrtest-*, but it would be nicer if the environment allowed 
them to run. (Not testing SSL seems a bit shoddy.)

Jeff Allen

On 13/03/2017 20:07, Adam Burke wrote:
> If test_socket and test_ssl fail due to environmental reasons - eg can't reliably obtain a non-clashing socket on the build server - it's probably worth having a mechanism to distinguish and disable them in that environment.
>
> Test_sort seems like it should pass everywhere though?
>
> Adam
>
>> 在 2017年3月13日，下午5:59，Jeff Allen <ja...@fa...> 写道：
>>
>> A while ago our GitHub repo
>> https://github.com/jythontools/jython/commits/master sprouted continuous
>> integration tests, thanks (I think) to Darjus. However, these tests
>> always fail.
>>
>> This seems to me to remove their primary value, which is as a tripwire
>> to tell us when something has broken, or when a PR would break it.
>> That's particularly valuable where tests run on a different platform
>> from the developer's regression test.
>>
>> The tests failing at GitHub (over the various tools and test
>> conditions), that don't fail on the (= my Windows) desktop, are:
>>
>> test_socket test_sort test_ssl
>>
>> I'm tweaking the expected failures in regrtest to get it to run cleanly
>> again under ant on the desktop, as we encourage users to run that. But
>> perhaps the target should be to have it run cleanly at GitHub too,
>> adding things that don't to the "list of shame".
>>
>> Is it sensible to add as expected failures, those things that routinely
>> fail in the GitHub tests? Or do they fail for a reason we could
>> immediately fix by configuration there?
>>
>> Jeff
>>
>> -- 
>> Jeff Allen
>>
>>
>> ------------------------------------------------------------------------------
>> Announcing the Oxford Dictionaries API! The API offers world-renowned
>> dictionary content that is easy and intuitive to access. Sign up for an
>> account today to start using our lexical data to power your apps and
>> projects. Get started today and enter our developer competition.
>> http://sdm.link/oxford
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] Failing tests on GitHub

[Adam B. <ada...@gm...>]

If test_socket and test_ssl fail due to environmental reasons - eg can't reliably obtain a non-clashing socket on the build server - it's probably worth having a mechanism to distinguish and disable them in that environment.

Test_sort seems like it should pass everywhere though?

Adam

> 在 2017年3月13日，下午5:59，Jeff Allen <ja...@fa...> 写道：
> 
> A while ago our GitHub repo 
> https://github.com/jythontools/jython/commits/master sprouted continuous 
> integration tests, thanks (I think) to Darjus. However, these tests 
> always fail.
> 
> This seems to me to remove their primary value, which is as a tripwire 
> to tell us when something has broken, or when a PR would break it. 
> That's particularly valuable where tests run on a different platform 
> from the developer's regression test.
> 
> The tests failing at GitHub (over the various tools and test 
> conditions), that don't fail on the (= my Windows) desktop, are:
> 
> test_socket test_sort test_ssl
> 
> I'm tweaking the expected failures in regrtest to get it to run cleanly 
> again under ant on the desktop, as we encourage users to run that. But 
> perhaps the target should be to have it run cleanly at GitHub too, 
> adding things that don't to the "list of shame".
> 
> Is it sensible to add as expected failures, those things that routinely 
> fail in the GitHub tests? Or do they fail for a reason we could 
> immediately fix by configuration there?
> 
> Jeff
> 
> -- 
> Jeff Allen
> 
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

[Jython-dev] Failing tests on GitHub

[Jeff A. <ja...@fa...>]

A while ago our GitHub repo 
https://github.com/jythontools/jython/commits/master sprouted continuous 
integration tests, thanks (I think) to Darjus. However, these tests 
always fail.

This seems to me to remove their primary value, which is as a tripwire 
to tell us when something has broken, or when a PR would break it. 
That's particularly valuable where tests run on a different platform 
from the developer's regression test.

The tests failing at GitHub (over the various tools and test 
conditions), that don't fail on the (= my Windows) desktop, are:

test_socket test_sort test_ssl

I'm tweaking the expected failures in regrtest to get it to run cleanly 
again under ant on the desktop, as we encourage users to run that. But 
perhaps the target should be to have it run cleanly at GitHub too, 
adding things that don't to the "list of shame".

Is it sensible to add as expected failures, those things that routinely 
fail in the GitHub tests? Or do they fail for a reason we could 
immediately fix by configuration there?

Jeff

-- 
Jeff Allen

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2017-03-03 - 2017-03-10)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     306 ( +1)
  closed  2279 ( +2)
  total   2585 ( +3)

Open issues with patches: 29   


Issues opened (3)
=================

#2564: test_socket_jy fails on Linux
http://bugs.jython.org/issue2564  opened by stefan.richthofer

#2565: test_jy_internal deadlock on Windows
http://bugs.jython.org/issue2565  opened by jamesmudd

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566  opened by fwyzard



Most recent 15 issues with no replies (15)
==========================================

#2562: Windows: OSError: unlink(): an unknown error occurred
http://bugs.jython.org/issue2562

#2543: broken links for mailing list website
http://bugs.jython.org/issue2543

#2540: settrace doesn't notice "with" statements
http://bugs.jython.org/issue2540

#2531: Support SNI for SSL/TLS server sockets
http://bugs.jython.org/issue2531

#2525: Jython incorrectly buffers file pipe output with Subprocess(co
http://bugs.jython.org/issue2525

#2520: Jython does NOT support socket.listen(0) for accepting only on
http://bugs.jython.org/issue2520

#2512: Values in built-in modules's __dict__ are “<reflected field 
http://bugs.jython.org/issue2512

#2510: TypeError when monkey-patching time.time with an unbound funct
http://bugs.jython.org/issue2510

#2507: Run "invokeFunction" in a thread does not inherit the "ScriptC
http://bugs.jython.org/issue2507

#2494: Support for pydoc_data
http://bugs.jython.org/issue2494

#2484: Codec encodings can exhaust permgen
http://bugs.jython.org/issue2484

#2482: Publish U.S. ECCN for Jython
http://bugs.jython.org/issue2482

#2422: test_classpathimporter fauls on Linux
http://bugs.jython.org/issue2422

#2418: test_chdir subprocess tests fail on Windows
http://bugs.jython.org/issue2418

#2410: Regression in PySystemStateTest (leading slash)
http://bugs.jython.org/issue2410



Most recent 15 issues waiting for review (15)
=============================================

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566

#2565: test_jy_internal deadlock on Windows
http://bugs.jython.org/issue2565

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embedd other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1866: Parser does not have mismatch token error messages caught by B
http://bugs.jython.org/issue1866

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842



Top 10 most discussed issues (6)
================================

#2559: test_marshal fails
http://bugs.jython.org/issue2559   7 msgs

#2554: regrtest failures on Windows
http://bugs.jython.org/issue2554   6 msgs

#2564: test_socket_jy fails on Linux
http://bugs.jython.org/issue2564   6 msgs

#2504: datetime.date.__tojava__ returns incorrect dates in non-UTC ti
http://bugs.jython.org/issue2504   5 msgs

#2565: test_jy_internal deadlock on Windows
http://bugs.jython.org/issue2565   5 msgs

#2566: inspect does not recognize code objects from bytecode files
http://bugs.jython.org/issue2566   3 msgs



Issues closed (2)
=================

#2314: test_shutil failures on Windows
http://bugs.jython.org/issue2314  closed by jeff.allen

#2500: Loading default cacerts on client socket when specifying a def
http://bugs.jython.org/issue2500  closed by darjus

Re: [Jython-dev] bean names and get/set

[Sommers, R. <Rog...@co...>]

Hi Adam,

This sounds like it could be an option, thanks. I’ll have a look when I get the time. It might increase the startup time, though (already nearly 20s to load and initialise our libraries).

Cheers
-Roger.



From: Adam Burke [mailto:ada...@gm...]
Sent: 09 March 2017 10:45
To: Sommers, Roger
Cc: Jeff Allen; jyt...@li...
Subject: Re: [Jython-dev] bean names and get/set


Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

If I'm following correctly, you should be able to write a short decorator utility in pure Python that does this by adding aliases to the ___dict___, or similar? Something extending the basic idea here:

http://stackoverflow.com/questions/1305532/convert-python-dict-to-object

You wouldn't need to hand craft decorators for all your Java API, just make the entry point to your API a python module that knows the name of your Java package and calls this aliasing utility once on each class at import time.

If that turns out fairly clean it might be a useful utility to add, as being able to have the same script in IronPython and Jython does sound good.
Adam

在 2017年3月9日，上午4:53，Sommers, Roger <Rog...@co...<mailto:Rog...@co...>> 写道：
Hi Jeff, thanks for the reply. Some comments are inline.

From: Jeff Allen [mailto:ja...@fa...]
Sent: 09 March 2017 08:26
To: Sommers, Roger
Cc: jyt...@li...<mailto:jyt...@li...>
Subject: Re: [Jython-dev] bean names and get/set


Roger:

I gave this a pause to see if anyone with longer history in Jython would chip in.

Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.

Sure. I used the word preserving because I wanted to distinguish between “use the name as-is without the get/set” and “force uppercase letter”. I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions.

I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.

Understood. I used “length” as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it’s generated code. But I would rather not have two setters and getters for each property.
I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.

That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements.

If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write.

I’m not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-).

If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment – to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries.

Thanks again for your time and for your considered reply, much appreciated!

-Roger.





Jeff Allen
On 07/03/2017 12:12, Sommers, Roger wrote:
Hi again,

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

Eg:

PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”
PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”
PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

Thanks again

-Roger.


From: Sommers, Roger
Sent: 07 March 2017 11:47
To: jyt...@li...<mailto:jyt...@li...>
Subject: [Jython-dev] bean names and get/set

Hi Jython developers,

First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.

I was wondering if you would consider a feature request or two:


1.       to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).

2.       To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.

Many thanks for your time
-Roger.

(C++, Java, C# and python developer)






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

Announcing the Oxford Dictionaries API! The API offers world-renowned

dictionary content that is easy and intuitive to access. Sign up for an

account today to start using our lexical data to power your apps and

projects. Get started today and enter our developer competition.

http://sdm.link/oxford





_______________________________________________

Jython-dev mailing list

Jyt...@li...<mailto:Jyt...@li...>

https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Jython-dev mailing list
Jyt...@li...<mailto:Jyt...@li...>
https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] bean names and get/set

[Adam B. <ada...@gm...>]

> Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

If I'm following correctly, you should be able to write a short decorator utility in pure Python that does this by adding aliases to the ___dict___, or similar? Something extending the basic idea here:

http://stackoverflow.com/questions/1305532/convert-python-dict-to-object

You wouldn't need to hand craft decorators for all your Java API, just make the entry point to your API a python module that knows the name of your Java package and calls this aliasing utility once on each class at import time.

If that turns out fairly clean it might be a useful utility to add, as being able to have the same script in IronPython and Jython does sound good.

Adam

> 在 2017年3月9日，上午4:53，Sommers, Roger <Rog...@co...> 写道：
> 
> Hi Jeff, thanks for the reply. Some comments are inline.
>  
> From: Jeff Allen [mailto:ja...@fa...] 
> Sent: 09 March 2017 08:26
> To: Sommers, Roger
> Cc: jyt...@li...
> Subject: Re: [Jython-dev] bean names and get/set
>  
> Roger:
> 
> I gave this a pause to see if anyone with longer history in Jython would chip in.
> 
> Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.
> 
> Sure. I used the word preserving because I wanted to distinguish between “use the name as-is without the get/set” and “force uppercase letter”. I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions.
> 
> I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").
> 
> A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.
> 
> Understood. I used “length” as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it’s generated code. But I would rather not have two setters and getters for each property.
> 
> I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.
>  
> That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements.
>  
> If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write.
>  
> I’m not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-).
>  
> If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?
>  
> Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.
>  
> The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment – to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries.
>  
> Thanks again for your time and for your considered reply, much appreciated!
>  
> -Roger.
> 
> 
> 
> Jeff Allen
> On 07/03/2017 12:12, Sommers, Roger wrote:
> Hi again,
>  
> I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.
>  
> Eg:
>  
> PyPreservePropertyCaseTag                 - getShape() generates readable property “Shape” instead of “shape”
> PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called “orCreateWidget”
> PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods
>  
> Thanks again
>  
> -Roger.
>  
>  
> From: Sommers, Roger 
> Sent: 07 March 2017 11:47
> To: jyt...@li...
> Subject: [Jython-dev] bean names and get/set
>  
> Hi Jython developers,
>  
> First off, thanks for your hard work developing Jython! I’m particularly impressed with how easy it is to get working with an existing jar.
>  
> I was wondering if you would consider a feature request or two:
>  
> 1.       to optionally preserve the case of bean names (eg getShape() -> property/bean “Shape” instead of “shape”). Something like python.options.preserveBeanNames = true (default false of course).
> 2.       To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(
>  
> The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won’t run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.
>  
> Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can’t stop them using the get/set methods without enhancement #2.
>  
> Many thanks for your time
> -Roger.
>  
> (C++, Java, C# and python developer)
>  
> 
> 
> 
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> 
> 
> 
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>  
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] bean names and get/set

[Sommers, R. <Rog...@co...>]

Hi Jeff, thanks for the reply. Some comments are inline.

From: Jeff Allen [mailto:ja...@fa...]
Sent: 09 March 2017 08:26
To: Sommers, Roger
Cc: jyt...@li...
Subject: Re: [Jython-dev] bean names and get/set


Roger:

I gave this a pause to see if anyone with longer history in Jython would chip in.

Under JavaBeans conventions, property names start with a lower case letter (see https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), and that tends to be the case in Python. Sure, the getter and setters are getLength and setLength, but the property is called "length". So making it "x.Length" is not a question of preserving the case, but of using a non-Java convention while exposing them to Python.

Sure. I used the word preserving because I wanted to distinguish between "use the name as-is without the get/set" and "force uppercase letter". I appreciate the reasons why it is done the way it is, and following the bean convention is a perfectly sensible choice. I am merely suggesting an option to allow Java developers more control over what the Jython interface to their library looks like. For example, they might decide to use lower-case properties for read-only values, who knows. The use case for me happens to be closer alignment with C# conventions.

I don't know C#, but you've explained that C# names its properties with an initial upper case, and the default exposure in IronPython of a C# class leaves that as it is. You have code you want to run in both interpreters that gives an interpretation to x.Length when x is a C# object of class X, and you want the same interpretation to be given y.length when y is a JavaBean of type Y (or maybe any Java object of class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean compatible things?". (He would ask the same about X.a and Y.a if the identically named member 'a' were not the attribute of a common base or interface.) And the Pythonist would probably reply something about duck typing. Duck-typing always poses risks to correctness: it's an assumption that length (or write, etc.) means the same thing on several unrelated classes. But the motivation for Jython to take the risk with the well-established JavaBeans convention is clear.

Understood. I used "length" as an example, but in my particular instance I do in fact generate the jar and assembly (it is our own code), and I know the properties mean the same thing in both. In theory I could just add the lower case version to the C# (ie, have both upper and lower), in fact this would be easy because it's generated code. But I would rather not have two setters and getters for each property.
I think what you're asking is: please provide a way to interpret in Jython, the interface offered by Java objects, that makes them name-similar to C# objects wrapped by IronPython, assuming similar names mean the same thing.

That is precisely it. Perhaps my case is a little unusual in that I am using both IronPython and Jython to (conceptually) wrap the same library. You might ask why; the answer is that there is some demand for Excel integration, which IronPython is good at, but we also want to provide python support for linux and unix-based users. We are at the early stages of python adoption, and not much python code has been written yet. Before people go off and write loads of scripts using one implementation, I am trying to take steps to ensure that what they write can (largely) be used in the other. Where the language semantics differ (eg Streams vs Readers), I have provided a utils module that hides such differences, but the object library, which forms the vast bulk of the interface, can be brought into close alignment with these enhancements.

If that's a fair summary, I'm doubtful that's a thing one ought to bake into the Jython interpreter. I can see practical difficulties too, since exposure gets done once after installation, and the cached exposure is used globally, affecting the names seen by code you didn't write.

I'm not sure I understand this point. I am not suggesting we change the default behaviour, the only thing I am looking to bake in is more flexibility :-).

If this has to be done by tagging-up (the wrapped version of) those Java classes and methods, more or less individually crafted, could the same not be achieved by wrappers (probably decorators) at the Python level, in a distinct library/utility, used just where needed?

Yes, but in my case such a wrapper library would contain in excess of 10K methods. Another option is to write my own native python binding for our library, which seems a shame when Jython does 99% of what I need.

The tagged exception idea in Jython works well and is a clever idea, but there is only one example of its use at the moment - to completely ignore a method. I am suggesting more uses of it to give those deploying Jython to users more flexibility over the Jython interface to their libraries.

Thanks again for your time and for your considered reply, much appreciated!

-Roger.




Jeff Allen
On 07/03/2017 12:12, Sommers, Roger wrote:
Hi again,

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

Eg:

PyPreservePropertyCaseTag                 - getShape() generates readable property "Shape" instead of "shape"
PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called "orCreateWidget"
PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

Thanks again

-Roger.


From: Sommers, Roger
Sent: 07 March 2017 11:47
To: jyt...@li...<mailto:jyt...@li...>
Subject: [Jython-dev] bean names and get/set

Hi Jython developers,

First off, thanks for your hard work developing Jython! I'm particularly impressed with how easy it is to get working with an existing jar.

I was wondering if you would consider a feature request or two:


1.       to optionally preserve the case of bean names (eg getShape() -> property/bean "Shape" instead of "shape"). Something like python.options.preserveBeanNames = true (default false of course).

2.       To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won't run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can't stop them using the get/set methods without enhancement #2.

Many thanks for your time
-Roger.

(C++, Java, C# and python developer)





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

Announcing the Oxford Dictionaries API! The API offers world-renowned

dictionary content that is easy and intuitive to access. Sign up for an

account today to start using our lexical data to power your apps and

projects. Get started today and enter our developer competition.

http://sdm.link/oxford




_______________________________________________

Jython-dev mailing list

Jyt...@li...<mailto:Jyt...@li...>

https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] bean names and get/set

[Jeff A. <ja...@fa...>]

Roger:

I gave this a pause to see if anyone with longer history in Jython would 
chip in.

Under JavaBeans conventions, property names start with a lower case 
letter (see 
https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html), 
and that tends to be the case in Python. Sure, the getter and setters 
are getLength and setLength, but the property is called "length". So 
making it "x.Length" is not a question of *preserving* the case, but of 
using a non-Java convention while exposing them to Python.

I don't know C#, but you've explained that C# names its properties with 
an initial upper case, and the default exposure in IronPython of a C# 
class leaves that as it is. You have code you want to run in both 
interpreters that gives an interpretation to x.Length when x is a C# 
object of class X, and you want the same interpretation to be given 
y.length when y is a JavaBean of type Y (or maybe any Java object of 
class Y with visible member "length").

A language purist might ask "how do you know X.Length and Y.length mean 
compatible things?". (He would ask the same about X.a and Y.a if the 
identically named member 'a' were not the attribute of a common base or 
interface.) And the Pythonist would probably reply something about duck 
typing. Duck-typing always poses risks to correctness: it's an 
assumption that length (or write, etc.) means the same thing on several 
unrelated classes. But the motivation for Jython to take the risk with 
the well-established JavaBeans convention is clear.

I think what you're asking is: please provide a way to interpret in 
Jython, the interface offered by Java objects, that makes them 
name-similar to C# objects wrapped by IronPython, assuming similar names 
mean the same thing.

If that's a fair summary, I'm doubtful that's a thing one ought to bake 
into the Jython interpreter. I can see practical difficulties too, since 
exposure gets done once after installation, and the cached exposure is 
used globally, affecting the names seen by code you didn't write. If 
this has to be done by tagging-up (the wrapped version of) those Java 
classes and methods, more or less individually crafted, could the same 
not be achieved by wrappers (probably decorators) at the Python level, 
in a distinct library/utility, used just where needed?

Jeff Allen

On 07/03/2017 12:12, Sommers, Roger wrote:
>
> Hi again,
>
> I have just realised that using global options is not the best 
> approach. A better implementation (assuming any of this is deemed 
> worth doing) would be to expand on the exception tag mechanism to give 
> control on a method-by-method basis.
>
> Eg:
>
> PyPreservePropertyCaseTag - getShape() generates readable property 
> “Shape” instead of “shape”
>
> PyInhibitPropertyConversionTag - eg getOrCreateWidget() (a function 
> that creates a new Widget if this.widget==null) does not generate a 
> property called “orCreateWidget”
>
> PyHideMethodTag - specified method is hidden but property is still 
> generated (different from /PyIgnoreMethodTag/). Can be used to hide 
> set and get methods
>
> Thanks again
>
> -Roger.
>
> *From:*Sommers, Roger
> *Sent:* 07 March 2017 11:47
> *To:* jyt...@li...
> *Subject:* [Jython-dev] bean names and get/set
>
> Hi Jython developers,
>
> First off, thanks for your hard work developing Jython! I’m 
> particularly impressed with how easy it is to get working with an 
> existing jar.
>
> I was wondering if you would consider a feature request or two:
>
> 1.to optionally preserve the case of bean names (eg getShape() -> 
> property/bean “Shape” instead of “shape”). Something like 
> python.options.preserveBeanNames = true (default false of course).
>
> 2.To optionally hide the getShape() and setShape() methods when they 
> are identified as/converted to properties. Perhaps 
> python.options.hideGetSetMethods = true (default false). If I use 
> /PyIgnoreMethodTag /the methods get hidden, but so does the 
> bean/property. :-(
>
> The reason for asking is to improve the interoperability between 
> Jython and IronPython. We have a system where a library is usable by 
> both, and the C# uses properties exclusively that start with upper 
> case names. Hence, scripts written for Jython (x.length=4) won’t run 
> in IronPython (x.Length=4) and vice versa. We very much want to 
> support Jython, as we use Linux and other non-windows platforms. I 
> understand that the lower-casing of the first letter is a convention, 
> which I respect, but it would be useful to be able to choose.
>
> Regarding enhancement #2, users who decide to use the set/get method 
> style of access will find their python non-portable to IronPython, so 
> we want to encourage the property style of usage everywhere, but we 
> can’t stop them using the get/set methods without enhancement #2.
>
> Many thanks for your time
>
> -Roger.
>
> (C++, Java, C# and python developer)
>
>
>
> ------------------------------------------------------------------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

Re: [Jython-dev] bean names and get/set

[Sommers, R. <Rog...@co...>]

Hi again,

I have just realised that using global options is not the best approach. A better implementation (assuming any of this is deemed worth doing) would be to expand on the exception tag mechanism to give control on a method-by-method basis.

Eg:

PyPreservePropertyCaseTag                 - getShape() generates readable property "Shape" instead of "shape"
PyInhibitPropertyConversionTag            - eg getOrCreateWidget() (a function that creates a new Widget if this.widget==null) does not generate a property called "orCreateWidget"
PyHideMethodTag                                 - specified method is hidden but property is still generated (different from PyIgnoreMethodTag). Can be used to hide set and get methods

Thanks again

-Roger.


From: Sommers, Roger
Sent: 07 March 2017 11:47
To: jyt...@li...
Subject: [Jython-dev] bean names and get/set

Hi Jython developers,

First off, thanks for your hard work developing Jython! I'm particularly impressed with how easy it is to get working with an existing jar.

I was wondering if you would consider a feature request or two:


1.     to optionally preserve the case of bean names (eg getShape() -> property/bean "Shape" instead of "shape"). Something like python.options.preserveBeanNames = true (default false of course).

2.     To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won't run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can't stop them using the get/set methods without enhancement #2.

Many thanks for your time
-Roger.

(C++, Java, C# and python developer)

[Jython-dev] bean names and get/set

[Sommers, R. <Rog...@co...>]

Hi Jython developers,

First off, thanks for your hard work developing Jython! I'm particularly impressed with how easy it is to get working with an existing jar.

I was wondering if you would consider a feature request or two:


1.     to optionally preserve the case of bean names (eg getShape() -> property/bean "Shape" instead of "shape"). Something like python.options.preserveBeanNames = true (default false of course).

2.     To optionally hide the getShape() and setShape() methods when they are identified as/converted to properties. Perhaps python.options.hideGetSetMethods = true (default false). If I use PyIgnoreMethodTag the methods get hidden, but so does the bean/property. :-(

The reason for asking is to improve the interoperability between Jython and IronPython. We have a system where a library is usable by both, and the C# uses properties exclusively that start with upper case names. Hence, scripts written for Jython (x.length=4) won't run in IronPython (x.Length=4) and vice versa. We very much want to support Jython, as we use Linux and other non-windows platforms. I understand that the lower-casing of the first letter is a convention, which I respect, but it would be useful to be able to choose.

Regarding enhancement #2, users who decide to use the set/get method style of access will find their python non-portable to IronPython, so we want to encourage the property style of usage everywhere, but we can't stop them using the get/set methods without enhancement #2.

Many thanks for your time
-Roger.

(C++, Java, C# and python developer)

[Jython-dev] Is someone able to review PR 40 / #2500 proposed fix?

[Stefan R. <Ste...@gm...>]

We still have an unreviewed PR https://github.com/jythontools/jython/pull/40 proposing a fix for #2500 (Loading default cacerts on client socket when specifying a default java truststore unnecessarily searches for more cacerts in the same dir).
I am not an expert for ssl.py and cannot sufficiently asses whether it can/should be applied, although it looks good to me (in my local experimentation branch it doesn't cause regrtest issues or so).

I think it would be a pity to miss a ready-made fix for 2.7.1/rc, so it would be nice if someone with more knowledge about ssl, cacerts etc could have a look and drop a note.


Best

Stefan

Re: [Jython-dev] Jython 2.7.1 rc1 soft release

[Jeff A. <ja...@fa...>]

I kicked the tyres anyway (Windows 10, java1.8.0_121). I made a default 
installation and it went fine.

pip worked for me ("pip install Jinja2"), which was the main oversight 
in 2.7.0, so that's an important step forward.

"jython -m test.regrtest -e" hangs at test_logging, 
test_pythoninterpreter_jy, test_socket_jy, although these run ok when 
called individually under regrtest (and pass). It is as if some 
preceding test prepared the ground for these to hang, but I can't infer 
under what conditions.

With those excluded, it runs to completion, but not cleanly, reporting:

14 fails unexpected:
     test___all__ test_classpathimporter test_codecencodings_tw test_io
     test_io_jy test_java_integration test_jython_initializer
     test_marshal test_platform test_select_new test_sort test_ssl
     test_univnewlines test_zipimport_jy

I'll poke at these some more myself, but is it not the same for others?

Jeff Allen

On 28/02/2017 16:35, fwi...@gm... wrote:
> On Mon, Feb 27, 2017 at 8:51 PM, fwi...@gm...
> <fwi...@gm...> wrote:
>> Hi all,
>>
>> I've put together a soft release of 2.7.1 rc1.
>> Please test, especially if you can test on windows!
>>
>> As soon as I get a couple of sanity checks, I'll finalize the RC and
>> do a real announcement.
> Stefan asked me to hold off on finalizing the RC until he can do a
> standard lib update, so it will probably be another day or two before
> I finalize.
>
> -Frank
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

[Jython-dev] Summary of Jython tracker Issues

[Jython t. <st...@bu...>]

ACTIVITY SUMMARY (2017-02-24 - 2017-03-03)
Jython tracker at http://bugs.jython.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open     305 (-13)
  closed  2277 (+19)
  total   2582 ( +6)

Open issues with patches: 27   


Issues opened (6)
=================

#2558: Feature request: Automatic string to enum coercion
http://bugs.jython.org/issue2558  opened by jamesmudd

#2559: test_marshal fails
http://bugs.jython.org/issue2559  opened by jamesmudd

#2560: StackOverflowError with multiple inheritance, metaclasses, and
http://bugs.jython.org/issue2560  opened by refi64

#2561: win32_ver raises exception
http://bugs.jython.org/issue2561  opened by stefan.richthofer

#2562: Windows: OSError: unlink(): an unknown error occurred
http://bugs.jython.org/issue2562  opened by stefan.richthofer

#2563: Windows: ValueError: invalid encoding: None
http://bugs.jython.org/issue2563  opened by stefan.richthofer



Most recent 15 issues with no replies (15)
==========================================

#2563: Windows: ValueError: invalid encoding: None
http://bugs.jython.org/issue2563

#2562: Windows: OSError: unlink(): an unknown error occurred
http://bugs.jython.org/issue2562

#2561: win32_ver raises exception
http://bugs.jython.org/issue2561

#2554: regrtest failures on Windows
http://bugs.jython.org/issue2554

#2543: broken links for mailing list website
http://bugs.jython.org/issue2543

#2540: settrace doesn't notice "with" statements
http://bugs.jython.org/issue2540

#2531: Support SNI for SSL/TLS server sockets
http://bugs.jython.org/issue2531

#2525: Jython incorrectly buffers file pipe output with Subprocess(co
http://bugs.jython.org/issue2525

#2524: datetime <-> time conversion incorrect in non UTC times
http://bugs.jython.org/issue2524

#2520: Jython does NOT support socket.listen(0) for accepting only on
http://bugs.jython.org/issue2520

#2512: Values in built-in modules's __dict__ are “<reflected field 
http://bugs.jython.org/issue2512

#2510: TypeError when monkey-patching time.time with an unbound funct
http://bugs.jython.org/issue2510

#2507: Run "invokeFunction" in a thread does not inherit the "ScriptC
http://bugs.jython.org/issue2507

#2494: Support for pydoc_data
http://bugs.jython.org/issue2494

#2484: Codec encodings can exhaust permgen
http://bugs.jython.org/issue2484



Most recent 15 issues waiting for review (15)
=============================================

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545

#2429: cStringIO does not work with mutable objects implementing the 
http://bugs.jython.org/issue2429

#2367: Jython ignores custom __eq__ when hashing dict subclasses
http://bugs.jython.org/issue2367

#2330: full-build fails to copy CPython License
http://bugs.jython.org/issue2330

#2230: Jython evaluation blocks under heavy load with high multi-core
http://bugs.jython.org/issue2230

#2143: site-packages support in standalone jar
http://bugs.jython.org/issue2143

#2142: Set Thread classloader when entering Jython context
http://bugs.jython.org/issue2142

#2121: Jython jar on Maven central embedd other third party libraries
http://bugs.jython.org/issue2121

#2077: marshal doesn't raise error when fed unmarshalable object
http://bugs.jython.org/issue2077

#1925: Support loading java.sql.Drivers that aren't on the boot class
http://bugs.jython.org/issue1925

#1917: No ctypes.c_char
http://bugs.jython.org/issue1917

#1866: Parser does not have mismatch token error messages caught by B
http://bugs.jython.org/issue1866

#1842: Add IBM i support to Jython
http://bugs.jython.org/issue1842

#1796: Jython doesn't support jar dir with colon's in it
http://bugs.jython.org/issue1796

#1741: com.ziclix.python.sql.DataHandler calls wasNull without previo
http://bugs.jython.org/issue1741



Top 10 most discussed issues (4)
================================

#2521: Windows installation (all) fails on Windows 10
http://bugs.jython.org/issue2521   9 msgs

#2545: help() does not work on Java-implemented modules
http://bugs.jython.org/issue2545   4 msgs

#2559: test_marshal fails
http://bugs.jython.org/issue2559   4 msgs

#527524: Cannot compile to use methods exceeding JVM size restrictions
http://bugs.jython.org/issue527524   3 msgs



Issues closed (1)
=================

#2556: meta: Github mirror is behind the Mercurial one
http://bugs.jython.org/issue2556  closed by darjus