jython-users — Discussion of and questions about using Jython

[Jython-users] Using Jbang to run Jython scripts with Maven dependencies

[Werner F. <wer...@gm...>]

 Jython scripts occasionally require access to JAR files from Maven
Central. Unlike Groovy, Jython lacks a built-in mechanism to resolve these
dependencies. However, one can bootstrap a Jython script along with its
Maven dependencies using JBang. This technique ensures that your Jython
scripts can seamlessly access the necessary dependencies from Maven
Central. See https://www.jbang.dev/ for information about JBang.

<Step 1> - create file *Jython.java* with JBang support and required Maven
dependencies.

----------
///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS org.python:jython-standalone:2.7.4
//DEPS io.leego:banana:2.1.0
import org.python.util.jython;
public class Jython {
    public static void main(String... args) {
        jython.main(args);
    }
}
----------

<Step 2> - create a Jython script (*test.py*)

----------
from __future__ import print_function

import io.leego.banana.BananaUtils as BananaUtils
import io.leego.banana.Font as Font

text0 = "Jython 2.7"
text1 = BananaUtils.bananaify(text0, Font.STANDARD)

print(text1)
----------

<Step 3> -run the Jython script

$ jbang run Jython.java test.py

[jbang] Resolving dependencies...
[jbang]    org.python:jython-standalone:2.7.4
[jbang]    io.leego:banana:2.1.0
[jbang] Dependencies resolved
[jbang] Building jar for Jython.java...
Jython 2.7    # Displayed as banner text

Happy Jython scripting!
-- 
Werner Fouché

[Jython-users] Jython 2.7.4 available

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

The project is happy to announce the general availability of Jython 
2.7.4 at https://www.jython.org/download .

v2.7.4 is a contains minor bug-fixes (thanks to all who contributed to 
triage and PRs) and security fixes by way of updated dependency JARs. 
Fuller details are at the link above, by following links on the page, 
and on our GitHub project.

-- 

Jeff Allen

Re: [Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?

[John H. <jhu...@ns...>]

Jeff,

Thanks again for pointing me in the right direction.  For anyone else who
stumbles across this thread I tracked the issue down and have opened [1].

[1] https://github.com/jython/jython/issues/335

--
Cheers
-john


On Fri, Jun 7, 2024 at 4:52 PM John Hubbard <jhu...@ns...> wrote:

> Thanks Jeff for the quick reply.
>
> The GH-221 tickets that the commit addressed sounds kind of like this
> because our AttributeTable class does in fact use varargs but there is a
> comment[1] in the ticket for what sounds exactly like my issue and
> tpoliaw's reply suggests that this isn't intended to fix it though.
>
> I went ahead and built the latest version of master locally and used that
> for testing and unfortunately it doesn't address my problem.  Now that I've
> actually built this myself, and armed with a pointer at where to look, I'll
> see if I can identify where things changed and work on a solution.  Don't
> worry about holding off on a 2.7.4 on our account.
>
> Thanks again!
>
> [1] https://github.com/jython/jython/issues/221#issuecomment-1784005688
> --
> Cheers
> -john
>
>
> On Fri, Jun 7, 2024 at 4:10 AM Jeff Allen <ja...@fa...> wrote:
>
>> This is maybe better as an issue, although it sounds like one that
>> already defeated us.
>>
>> 1. The code by which a call is matched to a method always looked somewhat
>> heuristic to me. (I believe this comes from a Greek word meaning "luck".)
>> As I understand it, it takes the first match, a match ocurring where the
>> arguments say they can produce the Java type in the signature. The sort
>> order of overloaded methods is therefore important. I think "What Would
>> Java Do?" is the aspiration, but I suspect this cannot be achieved just by
>> sorting. (Have we changed the sort? I didn't think so.) The best expression
>> of expected behaviour is probably in the tests `test_joverload.py` and
>> `javatests/Reflection.java`.
>>
>> 2. There has been some work in the matching to address variable numbers
>> of arguments, so some code change, late in 2.7.3 (I think) and in 2.7.4
>> (currently in beta). I might have blamed:
>> https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7
>> but I think it is later than you need to explain the change. However, I
>> think it is a good place to start. These are the source files right files
>> (probably).  Another possible cause is in "normalisations" that can occur
>> during assignment which I think we tweaked (to solve another problem, not
>> just for the heck of it).
>>
>> 3. You're asking to hook the `__tojava__` methods, which I don't *think*
>> you can do. It would be on built-in types too.
>>
>> How is it with 2.7.4b2? I think I wouldn't delay 2.7.4 for this, but
>> there's always a small hope your problem has gone away.
>>
>> Bets wishes,
>> Jeff
>>
>>
>> On 06/06/2024 22:38, John Hubbard wrote:
>>
>> Hello,
>>
>> Has something changed between Jython 2.7.2 and Jython 2.7.2 with regards
>> to how calls from Jython to an overloaded Java method are resolved?
>>
>> *Background*
>> I am trying to update our application from Jython 2.7.2 to Jython 2.7.3
>> and I have run into what I think is a change in how Jython handles
>> overloaded Java methods.  The primary motivation for the update is proper
>> handling of * imports under JDK 17 (and JUnit 5); see Jython GitHub issues
>> 105, 304 and maybe 309.
>>
>> Our application is primarily Java based but uses Jython for high level
>> scripts which perform high level sequencing.  One of the most common things
>> those scripts do is construct 'bags of data' which are handled by our
>> AttributeTable class (full jdoc here
>> <https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html>).
>> That class is backed by a Map<String, String[]> and stores heterogenous
>> data via various via getters and setters like:
>>
>> insert(String name, String value)
>> insert(String name, int value)
>>
>> insert(String name, boolean value)
>>
>> ...
>>
>> String getString(String name)
>>
>> int getInt(String name)
>>
>>
>> With Jython 2.7.2 I could could write a script like:
>>
>> tbl = AttributeTable();
>> name = 'name'
>> value = 27
>> tbl.insert(name, value)
>>
>> and it would behave as expected.  Jython would resolve the insert call
>> to  the Java AttributeTable.insert(String, int) method, the Java side would
>> then convert the integer 27 into the String "27" and store it in the map
>> for later use.
>>
>> *Problem*
>> With Jython 2.7.3 I think that the truthiness of the value is being
>> evaluated and AttributeTable.insert(String, boolean) is what is getting
>> triggered.  For example the following code:
>>
>> def savePropertyValue(appName, propertyName, propertyValue):
>>   print('savePropertyValue(' + str(appName) + ', ' + str(propertyName)
>>           + ', ' + str(propertyValue) + ')')
>>   at = AttributeTable()
>>   at.insert(propertyName, propertyValue)
>>   at.show('savePropertyValue() AttributeTable ')
>>
>> produces
>>
>> savePropertyValue(atst.ics.visp, atst.ics.visp.slitStepSz, 0.05)
>> savePropertyValue() AttributeTable atst.ics.visp.slitStepSz: true
>>
>>
>> So the value 0.05 was passed into the jython savePropertyValue function
>> but what ended up being inserted into the Java AttributeTable object was
>> the boolean true.
>>
>> *Questions*
>>
>>    1. What is the expected behavior when interacting with overloaded
>>    Java objects?  Were we just lucky before and this was never expected to
>>    work?
>>    2. Is anyone aware of changes on the Java side that may have
>>    triggered this?  I'd like some background on what might have caused this so
>>    I can investigate what might be improved to fix this.
>>    3. Is it possible to inject custom PyObject --> Java Object coercion
>>    routines?  The interpreters are setup at a high level; if I could mask the
>>    Java AttributeTable class with a Python class that better handled
>>    overloaded methods and then somehow coerce/convert it to an Java
>>    AttributeTable before sending it back into Java land I might be able to
>>    work around this.
>>
>> Thanks
>>
>> --
>> Cheers
>> -john
>>
>>
>> _______________________________________________
>> Jython-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/jython-users
>>
>> --
>>
>> Jeff Allen
>>
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-users
>>
>

Re: [Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?

[John H. <jhu...@ns...>]

Thanks Jeff for the quick reply.

The GH-221 tickets that the commit addressed sounds kind of like this
because our AttributeTable class does in fact use varargs but there is a
comment[1] in the ticket for what sounds exactly like my issue and
tpoliaw's reply suggests that this isn't intended to fix it though.

I went ahead and built the latest version of master locally and used that
for testing and unfortunately it doesn't address my problem.  Now that I've
actually built this myself, and armed with a pointer at where to look, I'll
see if I can identify where things changed and work on a solution.  Don't
worry about holding off on a 2.7.4 on our account.

Thanks again!

[1] https://github.com/jython/jython/issues/221#issuecomment-1784005688
--
Cheers
-john


On Fri, Jun 7, 2024 at 4:10 AM Jeff Allen <ja...@fa...> wrote:

> This is maybe better as an issue, although it sounds like one that already
> defeated us.
>
> 1. The code by which a call is matched to a method always looked somewhat
> heuristic to me. (I believe this comes from a Greek word meaning "luck".)
> As I understand it, it takes the first match, a match ocurring where the
> arguments say they can produce the Java type in the signature. The sort
> order of overloaded methods is therefore important. I think "What Would
> Java Do?" is the aspiration, but I suspect this cannot be achieved just by
> sorting. (Have we changed the sort? I didn't think so.) The best expression
> of expected behaviour is probably in the tests `test_joverload.py` and
> `javatests/Reflection.java`.
>
> 2. There has been some work in the matching to address variable numbers of
> arguments, so some code change, late in 2.7.3 (I think) and in 2.7.4
> (currently in beta). I might have blamed:
> https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7
> but I think it is later than you need to explain the change. However, I
> think it is a good place to start. These are the source files right files
> (probably).  Another possible cause is in "normalisations" that can occur
> during assignment which I think we tweaked (to solve another problem, not
> just for the heck of it).
>
> 3. You're asking to hook the `__tojava__` methods, which I don't *think*
> you can do. It would be on built-in types too.
>
> How is it with 2.7.4b2? I think I wouldn't delay 2.7.4 for this, but
> there's always a small hope your problem has gone away.
>
> Bets wishes,
> Jeff
>
>
> On 06/06/2024 22:38, John Hubbard wrote:
>
> Hello,
>
> Has something changed between Jython 2.7.2 and Jython 2.7.2 with regards
> to how calls from Jython to an overloaded Java method are resolved?
>
> *Background*
> I am trying to update our application from Jython 2.7.2 to Jython 2.7.3
> and I have run into what I think is a change in how Jython handles
> overloaded Java methods.  The primary motivation for the update is proper
> handling of * imports under JDK 17 (and JUnit 5); see Jython GitHub issues
> 105, 304 and maybe 309.
>
> Our application is primarily Java based but uses Jython for high level
> scripts which perform high level sequencing.  One of the most common things
> those scripts do is construct 'bags of data' which are handled by our
> AttributeTable class (full jdoc here
> <https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html>).
> That class is backed by a Map<String, String[]> and stores heterogenous
> data via various via getters and setters like:
>
> insert(String name, String value)
> insert(String name, int value)
>
> insert(String name, boolean value)
>
> ...
>
> String getString(String name)
>
> int getInt(String name)
>
>
> With Jython 2.7.2 I could could write a script like:
>
> tbl = AttributeTable();
> name = 'name'
> value = 27
> tbl.insert(name, value)
>
> and it would behave as expected.  Jython would resolve the insert call to
> the Java AttributeTable.insert(String, int) method, the Java side would
> then convert the integer 27 into the String "27" and store it in the map
> for later use.
>
> *Problem*
> With Jython 2.7.3 I think that the truthiness of the value is being
> evaluated and AttributeTable.insert(String, boolean) is what is getting
> triggered.  For example the following code:
>
> def savePropertyValue(appName, propertyName, propertyValue):
>   print('savePropertyValue(' + str(appName) + ', ' + str(propertyName)
>           + ', ' + str(propertyValue) + ')')
>   at = AttributeTable()
>   at.insert(propertyName, propertyValue)
>   at.show('savePropertyValue() AttributeTable ')
>
> produces
>
> savePropertyValue(atst.ics.visp, atst.ics.visp.slitStepSz, 0.05)
> savePropertyValue() AttributeTable atst.ics.visp.slitStepSz: true
>
>
> So the value 0.05 was passed into the jython savePropertyValue function
> but what ended up being inserted into the Java AttributeTable object was
> the boolean true.
>
> *Questions*
>
>    1. What is the expected behavior when interacting with overloaded Java
>    objects?  Were we just lucky before and this was never expected to work?
>    2. Is anyone aware of changes on the Java side that may have triggered
>    this?  I'd like some background on what might have caused this so I can
>    investigate what might be improved to fix this.
>    3. Is it possible to inject custom PyObject --> Java Object coercion
>    routines?  The interpreters are setup at a high level; if I could mask the
>    Java AttributeTable class with a Python class that better handled
>    overloaded methods and then somehow coerce/convert it to an Java
>    AttributeTable before sending it back into Java land I might be able to
>    work around this.
>
> Thanks
>
> --
> Cheers
> -john
>
>
> _______________________________________________
> Jython-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/jython-users
>
> --
>
> Jeff Allen
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>

Re: [Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Would just add the small footnote that default-but-not-contracted sort orders have changed across JVM versions in the past.</div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Adam</div><div dir="ltr"><br><blockquote type="cite">在 2024年6月7日，下午8:10，Jeff Allen &lt;ja...@fa...&gt; 写道：<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  
    <div class="moz-cite-prefix">This is maybe better as an issue,
      although it sounds like one that already defeated us.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">1. The code by which a call is matched
      to a method always looked somewhat heuristic to me. (I believe
      this comes from a Greek word meaning "luck".) As I understand it,
      it takes the first match, a match ocurring where the arguments say
      they can produce the Java type in the signature. The sort order of
      overloaded methods is therefore important. I think "What Would
      Java Do?" is the aspiration, but I suspect this cannot be achieved
      just by sorting. (Have we changed the sort? I didn't think so.)
      The best expression of expected behaviour is probably in the tests
      `test_joverload.py` and `javatests/Reflection.java`.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">2. There has been some work in the
      matching to address variable numbers of arguments, so some code
      change, late in 2.7.3 (I think) and in 2.7.4 (currently in beta).
      I might have blamed:
<a class="moz-txt-link-freetext" href="https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7">https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7</a>
      but I think it is later than you need to explain the change.
      However, I think it is a good place to start. These are the source
      files right files (probably).&nbsp; Another possible cause is in
      "normalisations" that can occur during assignment which I think we
      tweaked (to solve another problem, not just for the heck of it).<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">3. You're asking to hook the
      `__tojava__` methods, which I don't *think* you can do. It would
      be on built-in types too.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">How is it with 2.7.4b2? I think I
      wouldn't delay 2.7.4 for this, but there's always a small hope
      your problem has gone away.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Bets wishes,<br>
    </div>
    <div class="moz-cite-prefix">Jeff<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 06/06/2024 22:38, John Hubbard
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAO2imXwGeO1Gh+1i1zT0gAWX0mzoMNzvHWp=WqeGXZUp70U=jQ...@ma...">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">Hello,&nbsp;</div>
        <div dir="ltr"><br>
        </div>
        <div dir="ltr">Has something changed between Jython 2.7.2 and
          Jython 2.7.2 with regards to how calls from Jython to an
          overloaded Java method are resolved?&nbsp;&nbsp;<br>
          <div><br>
          </div>
          <div><b>Background</b><br>
          </div>
          <div>I am trying to update our application from Jython 2.7.2
            to Jython 2.7.3 and I have run into what I think is a change
            in how Jython handles overloaded Java methods.&nbsp; The primary
            motivation for the update is proper handling of * imports
            under JDK 17 (and JUnit 5); see Jython GitHub issues 105,
            304 and maybe 309.&nbsp;&nbsp;</div>
          <div><br>
          </div>
          <div>Our application is primarily Java based but uses Jython
            for high level scripts which perform high level sequencing.&nbsp;
            One of the most common things those scripts do is construct
            'bags of data' which are handled by our AttributeTable class
            (full jdoc <a href="https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html" target="_blank" moz-do-not-send="true">here</a>).&nbsp; That
            class is backed by a Map&lt;String, String[]&gt; and stores
            heterogenous data via various via getters and setters like:</div>
          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
            <div><font face="monospace">insert(String name, String
                value)</font></div>
            <div><font face="monospace">insert(String name, int value)</font></div>
          </blockquote>
          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
            <div><font face="monospace">insert(String name, boolean
                value)</font></div>
          </blockquote>
          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
            <div><font face="monospace">...</font></div>
          </blockquote>
          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
            <div><font face="monospace">String getString(String name)</font></div>
          </blockquote>
          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
            <div><font face="monospace">int getInt(String name)</font></div>
          </blockquote>
          <div><br>
          </div>
          <div>With Jython 2.7.2 I could could write a script like:</div>
          <blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
            <div><font face="monospace">tbl = AttributeTable();</font></div>
            <div><font face="monospace">name = 'name'</font></div>
            <div><font face="monospace">value = 27</font></div>
            <div><font face="monospace">tbl.insert(name, value)</font></div>
          </blockquote>
          <div>and it would behave as expected.&nbsp; Jython would resolve
            the insert call to&nbsp; the Java AttributeTable.insert(String,
            int) method, the Java side would then convert the integer 27
            into the String "27" and store it in the map for later
            use.&nbsp;&nbsp;</div>
          <div><br>
          </div>
          <div><b>Problem</b></div>
          <div>With Jython 2.7.3 I think that the truthiness of the
            value is being evaluated and AttributeTable.insert(String,
            boolean)&nbsp;is what is getting triggered.&nbsp; For example the
            following code:</div>
        </div>
        <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
          <div>
            <div>
              <div><font face="monospace">def savePropertyValue(appName,
                  propertyName, propertyValue):</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face="monospace">&nbsp; print('savePropertyValue(' +
                  str(appName) + ', ' + str(propertyName)</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face="monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; + ', ' +
                  str(propertyValue) + ')')</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face="monospace">&nbsp; at = AttributeTable()</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face="monospace">&nbsp; at.insert(propertyName,
                  propertyValue)</font></div>
            </div>
          </div>
          <div>
            <div>
              <div><font face="monospace">&nbsp; at.show('savePropertyValue()
                  AttributeTable ')</font></div>
            </div>
          </div>
        </blockquote>
        <div dir="ltr">
          <div>produces&nbsp;</div>
        </div>
        <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
          <div dir="ltr">
            <div><font face="monospace">savePropertyValue(atst.ics.visp,
                atst.ics.visp.slitStepSz, 0.05)<br>
                savePropertyValue() AttributeTable
                atst.ics.visp.slitStepSz: true</font><br>
            </div>
          </div>
        </blockquote>
        <div dir="ltr">
          <div><br>
          </div>
          <div>So the value 0.05 was passed into the jython
            savePropertyValue function but what ended up being inserted
            into the Java AttributeTable object was the boolean true.&nbsp;&nbsp;</div>
          <div><br>
          </div>
          <div><b>Questions</b></div>
          <div>
            <ol>
              <li>What is the expected behavior when interacting with
                overloaded Java objects?&nbsp; Were we just lucky before and
                this was never expected to work?</li>
              <li>Is anyone aware of changes on the Java side that may
                have triggered this?&nbsp; I'd like some background on what
                might have caused this so I can investigate what might
                be improved to fix this.</li>
              <li>Is it possible to inject custom PyObject --&gt; Java
                Object coercion routines?&nbsp; The interpreters are setup at
                a high level; if I could mask the Java AttributeTable
                class with a Python class that better handled overloaded
                methods and then somehow coerce/convert it to an Java
                AttributeTable before sending it back into Java land I
                might be able to work around this.</li>
            </ol>
            <div>Thanks</div>
          </div>
          <div><br>
          </div>
          <div>
            <div>
              <div dir="ltr" class="gmail_signature">
                <div dir="ltr">--
                  <div>Cheers</div>
                  <div>-john</div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Jython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Jyt...@li...">Jyt...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jython-users">https://lists.sourceforge.net/lists/listinfo/jython-users</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 

Jeff Allen
</pre>
  

<span>_______________________________________________</span><br><span>Jython-users mailing list</span><br><span>Jyt...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/jython-users</span><br></div></blockquote></body></html>

Re: [Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?

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

This is maybe better as an issue, although it sounds like one that 
already defeated us.

1. The code by which a call is matched to a method always looked 
somewhat heuristic to me. (I believe this comes from a Greek word 
meaning "luck".) As I understand it, it takes the first match, a match 
ocurring where the arguments say they can produce the Java type in the 
signature. The sort order of overloaded methods is therefore important. 
I think "What Would Java Do?" is the aspiration, but I suspect this 
cannot be achieved just by sorting. (Have we changed the sort? I didn't 
think so.) The best expression of expected behaviour is probably in the 
tests `test_joverload.py` and `javatests/Reflection.java`.

2. There has been some work in the matching to address variable numbers 
of arguments, so some code change, late in 2.7.3 (I think) and in 2.7.4 
(currently in beta). I might have blamed: 
https://github.com/jython/jython/commit/dd271a5edaa06925d45ef2d1477e3ec1cf6adfc7 
but I think it is later than you need to explain the change. However, I 
think it is a good place to start. These are the source files right 
files (probably).  Another possible cause is in "normalisations" that 
can occur during assignment which I think we tweaked (to solve another 
problem, not just for the heck of it).

3. You're asking to hook the `__tojava__` methods, which I don't *think* 
you can do. It would be on built-in types too.

How is it with 2.7.4b2? I think I wouldn't delay 2.7.4 for this, but 
there's always a small hope your problem has gone away.

Bets wishes,
Jeff


On 06/06/2024 22:38, John Hubbard wrote:
> Hello,
>
> Has something changed between Jython 2.7.2 and Jython 2.7.2 with 
> regards to how calls from Jython to an overloaded Java method are 
> resolved?
>
> *Background*
> I am trying to update our application from Jython 2.7.2 to Jython 
> 2.7.3 and I have run into what I think is a change in how Jython 
> handles overloaded Java methods.  The primary motivation for the 
> update is proper handling of * imports under JDK 17 (and JUnit 5); see 
> Jython GitHub issues 105, 304 and maybe 309.
>
> Our application is primarily Java based but uses Jython for high level 
> scripts which perform high level sequencing. One of the most common 
> things those scripts do is construct 'bags of data' which are handled 
> by our AttributeTable class (full jdoc here 
> <https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html>).  
> That class is backed by a Map<String, String[]> and stores 
> heterogenous data via various via getters and setters like:
>
>     insert(String name, String value)
>     insert(String name, int value)
>
>     insert(String name, boolean value)
>
>     ...
>
>     String getString(String name)
>
>     int getInt(String name)
>
>
> With Jython 2.7.2 I could could write a script like:
>
>     tbl = AttributeTable();
>     name = 'name'
>     value = 27
>     tbl.insert(name, value)
>
> and it would behave as expected.  Jython would resolve the insert call 
> to  the Java AttributeTable.insert(String, int) method, the Java side 
> would then convert the integer 27 into the String "27" and store it in 
> the map for later use.
>
> *Problem*
> With Jython 2.7.3 I think that the truthiness of the value is being 
> evaluated and AttributeTable.insert(String, boolean) is what is 
> getting triggered.  For example the following code:
>
>     def savePropertyValue(appName, propertyName, propertyValue):
>       print('savePropertyValue(' + str(appName) + ', ' + str(propertyName)
>               + ', ' + str(propertyValue) + ')')
>       at = AttributeTable()
>       at.insert(propertyName, propertyValue)
>       at.show('savePropertyValue() AttributeTable ')
>
> produces
>
>     savePropertyValue(atst.ics.visp, atst.ics.visp.slitStepSz, 0.05)
>     savePropertyValue() AttributeTable atst.ics.visp.slitStepSz: true
>
>
> So the value 0.05 was passed into the jython savePropertyValue 
> function but what ended up being inserted into the Java AttributeTable 
> object was the boolean true.
>
> *Questions*
>
>  1. What is the expected behavior when interacting with overloaded
>     Java objects?  Were we just lucky before and this was never
>     expected to work?
>  2. Is anyone aware of changes on the Java side that may have
>     triggered this?  I'd like some background on what might have
>     caused this so I can investigate what might be improved to fix this.
>  3. Is it possible to inject custom PyObject --> Java Object coercion
>     routines?  The interpreters are setup at a high level; if I could
>     mask the Java AttributeTable class with a Python class that better
>     handled overloaded methods and then somehow coerce/convert it to
>     an Java AttributeTable before sending it back into Java land I
>     might be able to work around this.
>
> Thanks
>
> -- 
> Cheers
> -john
>
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users

-- 

Jeff Allen

[Jython-users] Overloaded Java method handing changes between 2.7.2 and 2.7.3?

[John H. <jhu...@ns...>]

Hello,

Has something changed between Jython 2.7.2 and Jython 2.7.2 with regards to
how calls from Jython to an overloaded Java method are resolved?

*Background*
I am trying to update our application from Jython 2.7.2 to Jython 2.7.3 and
I have run into what I think is a change in how Jython handles overloaded
Java methods.  The primary motivation for the update is proper handling of
* imports under JDK 17 (and JUnit 5); see Jython GitHub issues 105, 304 and
maybe 309.

Our application is primarily Java based but uses Jython for high level
scripts which perform high level sequencing.  One of the most common things
those scripts do is construct 'bags of data' which are handled by our
AttributeTable class (full jdoc here
<https://share.nso.edu/shared/dkist/jhubbard/atst/atst/cs/interfaces/IAttributeTable.html>).
That class is backed by a Map<String, String[]> and stores heterogenous
data via various via getters and setters like:

insert(String name, String value)
insert(String name, int value)

insert(String name, boolean value)

...

String getString(String name)

int getInt(String name)


With Jython 2.7.2 I could could write a script like:

tbl = AttributeTable();
name = 'name'
value = 27
tbl.insert(name, value)

and it would behave as expected.  Jython would resolve the insert call to
the Java AttributeTable.insert(String, int) method, the Java side would
then convert the integer 27 into the String "27" and store it in the map
for later use.

*Problem*
With Jython 2.7.3 I think that the truthiness of the value is being
evaluated and AttributeTable.insert(String, boolean) is what is getting
triggered.  For example the following code:

def savePropertyValue(appName, propertyName, propertyValue):
  print('savePropertyValue(' + str(appName) + ', ' + str(propertyName)
          + ', ' + str(propertyValue) + ')')
  at = AttributeTable()
  at.insert(propertyName, propertyValue)
  at.show('savePropertyValue() AttributeTable ')

produces

savePropertyValue(atst.ics.visp, atst.ics.visp.slitStepSz, 0.05)
savePropertyValue() AttributeTable atst.ics.visp.slitStepSz: true


So the value 0.05 was passed into the jython savePropertyValue function but
what ended up being inserted into the Java AttributeTable object was the
boolean true.

*Questions*

   1. What is the expected behavior when interacting with overloaded Java
   objects?  Were we just lucky before and this was never expected to work?
   2. Is anyone aware of changes on the Java side that may have triggered
   this?  I'd like some background on what might have caused this so I can
   investigate what might be improved to fix this.
   3. Is it possible to inject custom PyObject --> Java Object coercion
   routines?  The interpreters are setup at a high level; if I could mask the
   Java AttributeTable class with a Python class that better handled
   overloaded methods and then somehow coerce/convert it to an Java
   AttributeTable before sending it back into Java land I might be able to
   work around this.

Thanks

--
Cheers
-john

Re: [Jython-users] Jython on APIdia

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

Stefan:

congratulations on bringing this to fruition!

It is now bookmarked at the top of my Jython menu. (That menu gets a lot 
of use, of course.)

I like the mouse-over that brings up parameter decsriptions. thanks for 
pointing that out. Also that clicking on a name from another project 
gives me a new tab (and still does so when I explicitly ask for one). 
Lots of other nice touches.

Almost my first question was "what other projects are here?". Oh, I see 
I can get a list if I start typing into the home page search. Quite a list!

Jeff



On 05/04/2024 01:08, Stefan Richthofer wrote:
> Dear Jythonistas, Jython and Java enthusiasts,
>
> with this email I proudly announce that a new Java API documentation 
> website is in town and Jython is among the first projects being 
> hosted. Please check it out at
>
> apidia.net/java/Jython <http://apidia.net/java/Jython>

-- 

Jeff Allen

[Jython-users] Jython on APIdia

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

Dear Jythonistas, Jython and Java enthusiasts,

with this email I proudly announce that a new Java API documentation
website is in town and Jython is among the first projects being hosted.
Please check it out at

apidia.net/java/Jython

The documentation resembles Javadoc but with some improvements.

Perhaps most notably, it revives the package and class side navigation,
which Javadoc used to have until Java 12. (That was removed due to
deprecation of frames. On APIdia, it is implemented in a future-proof way.)
The search field was intended as a replacement, but I always felt that a
structured API navigation and a search field are really two things. To
address that, on APIdia you have both.

Similar to Javadoc, the search field searches names of classes/interfaces
etc., members, packages and modules. On APIdia, it also features regex
functionality (e.g. "|", "^", "$" work as "or", "start" and "end",
respectively) with following special rules: spaces are interpreted as ".*",
which means you can type space-separated snippets of a long name to quickly
specify your target. If the search text contains a ".", fully qualified
names are searched.

While you navigate through docs, the site maintains a parameterized url
that can serve as a link to the current view state.

As of this writing, APIdia hosts the full Java 22 standard library and
several hundred artifacts from Maven Central. In addition to Jython, that
includes Guava, all other Jython dependencies, Netty, Jetty, JavaFX,
Jakarta and Java EE artifacts, most of Apache commons and Spring to some
extent. All hosted projects are fully interlinked.

Various design details are improved over Javadoc. To name some, function
args have mouseover tooltip texts (if corresponding docs are available).
Summary lines are robust: sentences do not end prematurely with common
abbreviations like "e.g.", "i.e." and so on. Common patterns such as "Note:
...", "Warning: ...", "Issue: ..." etc. are rendered as proper admonition
boxes. Functions transparently indicate if some other function is
overridden, implemented, hidden or redeclared, whether and where from doc
is inherited, and whether deprecation is inherited.

In the top-right menu, you can edit visibility settings and turn on private
methods, internal packages and modules. If you check and uncheck the boxes,
the site adjusts the displayed content accordingly. So, if you want to hack
on Jython internals, this is the place for you.

With this functionality, the site is still lightweight and fast. Since it
is free of tracking, you won't be bothered by annoying cookie banners.

What's more to say? APIdia launched just days ago, so what it needs now is
users. If you like the site, please spread the word to your fellow devs and
kindly provide feedback, so it can improve.

Happy API documentation browsing!

Stefan

[Jython-users] PyDev 12.0.0 Released

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

 PyDev 12.0.0 Release Highlights

   -

   *Debugger*
   - *sys.monitoring* is now used in Python 3.12 (and it's *much* faster
      than any previous version).
      - A new setting was added in the *Preferences > PyDev > Debug* to
      debug *just my code* (meaning that when stepping it will just step
      into files under PyDev source folders).
      - Improved the step into function (activated with *Ctrl+Alt* then *Click
      function* to step into).
      - Support for Python 3.6 and 3.7 was dropped (only Python 3.8 onwards
      is now supported).
   -

   *Ruff*
   - Ruff can now be used as a code formatter.
      - The latest ruff (*0.1.x*) is now supported (as it broke backward
      compatibility in its *0.1.0* version).
   -

   *Code Analysis*
   - Fixes in semantic analysis to better determine if strings in
      annotations should be checked for symbols or not.

Note: *Only Python 3.8 onwards is now supported*
* *Python 3.6* and *3.7* support is now *dropped* (please use *PyDev 11.0.3*
if you still use it).
About PyDev

PyDev is an open-source Python IDE on top of Eclipse for Python (also
available for Python on Visual Studio Code).

It comes with goodies such as code completion, syntax highlighting, syntax
analysis, code analysis, refactor, debug, interactive console, etc.

It is also available as a standalone through LiClipse with goodies such as
multiple cursors, theming and support for many other languages, such as
Django Templates, Jinja2, Html, JavaScript, etc.

Links:

PyDev: http://pydev.org
PyDev Blog: http://pydev.blogspot.com
PyDev on VSCode: http://pydev.org/vscode
LiClipse: http://www.liclipse.com
PyVmMonitor - Python Profiler: http://www.pyvmmonitor.com/

Cheers,

Fabio Zadrozny

Re: [Jython-users] Jython 3?

[Bill M. <bil...@gm...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr">Dear Jeff (and others),</div><div dir="ltr"><br></div><div dir="ltr">I wanted to add my words of encouragement towards developing a Python 3.x version of Jython. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">Your work, which provides the connection between the gentle, and user-friendly (programmer-friendly) Python syntax and great API, with the industrial-strength Java capabilities and API, makes all kinds of projects and work possible, that - chances are - you will never hear about. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">I am the co-developer of JythonMusic, which I now see is included as one of the many projects made possible through your work on Jython.org. (JythonMusic is available at JythonMusic.org.)</div><div dir="ltr"><br></div><div dir="ltr">Thank you for your great work. &nbsp;Words cannot begin to describe the appreciation felt on this end. &nbsp;You have made more than a decade of productive and creative works possible, and this is just on our end. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">This is to say that your work is being used in ways that you may never know. &nbsp; And is deeply appreciated. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">Thank you.&nbsp;</div><div dir="ltr"><br></div><div dir="ltr">Best,</div><div dir="ltr">Bill</div><div dir="ltr"><br></div><div dir="ltr"><div>--</div><div>Bill Manaris, Ph.D.</div><div>Professor, Computer Science</div><div>Director, Computing in the Arts</div><div>College of Charleston, USA</div><div>http://manaris.org</div><div>http://cita.cofc.edu</div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On Jul 25, 2023, at 2:50 AM, Jeff Allen &lt;ja...@fa...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  
    <p>Thanks to all who have given their +1s to this. I'm genuinely
      heartened that others think this is still worthwhile.</p>
    <p>There is a lot of change to take on between Python 2.7 and any
      recent 3 (not just print()), but also it seemed the time to
      implement the core in a more modern way.</p>
    <p>There was a time when I just wanted to try these ideas in a
      corner, in case the ideas were all wrong. (I hate wasting others'
      time.) It looks like they aren't *all* wrong. At the moment I'm
      working to integrate a contributed compiler front-end (Python to
      AST) which endeavor I think will drive forward other parts of the
      core still missing.<br>
    </p>
    <p>Jeff Allen</p>
    <div class="moz-cite-prefix">On 15/07/2023 13:32, John A. Hayes
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:D8B...@gm...">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      I think the conclusion from all this mail-list activity is there
      is great interest in a Jython 3.X. Rather than just saying I’m
      another +1 (which is true), is there a short-list of things that
      need to be achieved to reach Python 3+ compatibility?&nbsp;
      <div class=""><br class="">
      </div>
      <div class="">In my naive experience as a Python user, the most
        substantive difference between Python 2+ and Python 3+ was the
        transition between “print” being a statement in 2 and a function
        in 3 and that seems trivial. All the other changes were under
        the hood and not important from a user’s perspective.</div>
      <div class=""><br class="">
      </div>
      <div class="">If there are more corner cases, I’m happy to help,<br class="">
        <div class=""><br class="">
        </div>
        <div class="">All the best, and I’m a super big fan of the
          project; it’s just a bit mysterious how any of us can help.</div>
        <div class=""><br class="">
        </div>
        <div class="">John<br class="">
          <div><br class="">
            <blockquote type="cite" class="">
              <div class="">On Jul 15, 2023, at 1:31 AM, Liam Coughlin
                &lt;<a href="mailto:lsc...@gm..." class="moz-txt-link-freetext" moz-do-not-send="true">lsc...@gm...</a>&gt;
                wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <div dir="ltr" class="">+2 for jython 3 - wait am I
                  doing this right?<br class="">
                </div>
                <br class="">
                <div class="gmail_quote">
                  <div dir="ltr" class="gmail_attr">On Sat, Jul 15, 2023
                    at 2:13 AM Jon R. Fox &lt;<a href="mailto:drj...@gm..." class="moz-txt-link-freetext" moz-do-not-send="true">drj...@gm...</a>&gt;
                    wrote:<br class="">
                  </div>
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
                    <div dir="ltr" class="">
                      <div dir="ltr" class="">+1 for Jython 3.x</div>
                      <div class="">I'm using Groovy for now.</div>
                      <div dir="ltr" class="gmail_signature">
                        <div dir="ltr" class=""><br class="">
                        </div>
                      </div>
                    </div>
                    _______________________________________________<br class="">
                    Jython-users mailing list<br class="">
                    <a href="mailto:Jyt...@li..." target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">Jyt...@li...</a><br class="">
                    <a href="https://lists.sourceforge.net/lists/listinfo/jython-users" rel="noreferrer" target="_blank" class="moz-txt-link-freetext" moz-do-not-send="true">https://lists.sourceforge.net/lists/listinfo/jython-users</a><br class="">
                  </blockquote>
                </div>
                _______________________________________________<br class="">
                Jython-users mailing list<br class="">
                <a href="mailto:Jyt...@li..." class="moz-txt-link-freetext" moz-do-not-send="true">Jyt...@li...</a><br class="">
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jython-users">https://lists.sourceforge.net/lists/listinfo/jython-users</a><br class="">
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Jython-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Jyt...@li...">Jyt...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jython-users">https://lists.sourceforge.net/lists/listinfo/jython-users</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 

Jeff Allen
</pre>
  

<span>_______________________________________________</span><br><span>Jython-users mailing list</span><br><span>Jyt...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/jython-users</span><br></div></blockquote></div></body></html>

Re: [Jython-users] Jython 3?

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

Thanks to all who have given their +1s to this. I'm genuinely heartened 
that others think this is still worthwhile.

There is a lot of change to take on between Python 2.7 and any recent 3 
(not just print()), but also it seemed the time to implement the core in 
a more modern way.

There was a time when I just wanted to try these ideas in a corner, in 
case the ideas were all wrong. (I hate wasting others' time.) It looks 
like they aren't *all* wrong. At the moment I'm working to integrate a 
contributed compiler front-end (Python to AST) which endeavor I think 
will drive forward other parts of the core still missing.

Jeff Allen

On 15/07/2023 13:32, John A. Hayes wrote:
> I think the conclusion from all this mail-list activity is there is 
> great interest in a Jython 3.X. Rather than just saying I’m another +1 
> (which is true), is there a short-list of things that need to be 
> achieved to reach Python 3+ compatibility?
>
> In my naive experience as a Python user, the most substantive 
> difference between Python 2+ and Python 3+ was the transition between 
> “print” being a statement in 2 and a function in 3 and that seems 
> trivial. All the other changes were under the hood and not important 
> from a user’s perspective.
>
> If there are more corner cases, I’m happy to help,
>
> All the best, and I’m a super big fan of the project; it’s just a bit 
> mysterious how any of us can help.
>
> John
>
>> On Jul 15, 2023, at 1:31 AM, Liam Coughlin <lsc...@gm...> wrote:
>>
>> +2 for jython 3 - wait am I doing this right?
>>
>> On Sat, Jul 15, 2023 at 2:13 AM Jon R. Fox <drj...@gm...> wrote:
>>
>>     +1 for Jython 3.x
>>     I'm using Groovy for now.
>>
>>     _______________________________________________
>>     Jython-users mailing list
>>     Jyt...@li...
>>     https://lists.sourceforge.net/lists/listinfo/jython-users
>>
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-users
>
>
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users

-- 

Jeff Allen

Re: [Jython-users] Jython 3?

[John A. H. <ja...@gm...>]

Hi Stefan, 

Much appreciated for the feedback!

Cheers,

John

> On Jul 15, 2023, at 12:22 PM, Stefan Richthofer <ste...@gm...> wrote:
> 
> For the interested dev, Jython 3 is developed under the "main" branch: https://github.com/jython/jython/tree/main <https://github.com/jython/jython/tree/main>
> Also see https://www.jython.org/jython-3-roadmap <https://www.jython.org/jython-3-roadmap> and https://www.jython.org/jython-3-mvp <https://www.jython.org/jython-3-mvp>.
> Initially Python 3.8 was targeted since it was the Python version in development when the mvp discussion was formulated.
> The target version was, however, somewhat recently adjusted to Python 3.11.
> 
> Best,
> 
> -Stefan
> 
> Am Sa., 15. Juli 2023 um 17:09 Uhr schrieb Yaqiang Wang <yaq...@gm... <mailto:yaq...@gm...>>:
> Some of the features of Python 3 attract me in this document: https://www.asmeurer.com/python3-presentation/python3-presentation.pdf <https://www.asmeurer.com/python3-presentation/python3-presentation.pdf>, including features 2, 9, 11, 12.
> 
> Regards
> Yaqiang
> 
> On Sat, Jul 15, 2023 at 8:33 PM John A. Hayes <ja...@gm... <mailto:ja...@gm...>> wrote:
> I think the conclusion from all this mail-list activity is there is great interest in a Jython 3.X. Rather than just saying I’m another +1 (which is true), is there a short-list of things that need to be achieved to reach Python 3+ compatibility? 
> 
> In my naive experience as a Python user, the most substantive difference between Python 2+ and Python 3+ was the transition between “print” being a statement in 2 and a function in 3 and that seems trivial. All the other changes were under the hood and not important from a user’s perspective.
> 
> If there are more corner cases, I’m happy to help,
> 
> All the best, and I’m a super big fan of the project; it’s just a bit mysterious how any of us can help.
> 
> John
> 
>> On Jul 15, 2023, at 1:31 AM, Liam Coughlin <lsc...@gm... <mailto:lsc...@gm...>> wrote:
>> 
>> +2 for jython 3 - wait am I doing this right?
>> 
>> On Sat, Jul 15, 2023 at 2:13 AM Jon R. Fox <drj...@gm... <mailto:drj...@gm...>> wrote:
>> +1 for Jython 3.x
>> I'm using Groovy for now.
>> 
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li... <mailto:Jyt...@li...>
>> https://lists.sourceforge.net/lists/listinfo/jython-users <https://lists.sourceforge.net/lists/listinfo/jython-users>
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li... <mailto:Jyt...@li...>
>> https://lists.sourceforge.net/lists/listinfo/jython-users <https://lists.sourceforge.net/lists/listinfo/jython-users>
> 
> _______________________________________________
> Jython-users mailing list
> Jyt...@li... <mailto:Jyt...@li...>
> https://lists.sourceforge.net/lists/listinfo/jython-users <https://lists.sourceforge.net/lists/listinfo/jython-users>
> 
> 
> -- 
> *************************************************
> Dr. Yaqiang Wang
> Chinese Academy of Meteorological Sciences (CAMS)
> 46, Zhong-Guan-Cun South Avenue
> Beijing, 100081
> China
> 　　　　　　　　　　　　　
> yaq...@gm... <mailto:yaq...@gm...>
> 
> www.meteothink.org <http://www.meteothink.org/>
> **************************************************
> _______________________________________________
> Jython-users mailing list
> Jyt...@li... <mailto:Jyt...@li...>
> https://lists.sourceforge.net/lists/listinfo/jython-users <https://lists.sourceforge.net/lists/listinfo/jython-users>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users

Re: [Jython-users] Jython 3?

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

For the interested dev, Jython 3 is developed under the "main" branch:
https://github.com/jython/jython/tree/main
Also see https://www.jython.org/jython-3-roadmap and
https://www.jython.org/jython-3-mvp.
Initially Python 3.8 was targeted since it was the Python version in
development when the mvp discussion was formulated.
The target version was, however, somewhat recently adjusted to Python 3.11.

Best,

-Stefan

Am Sa., 15. Juli 2023 um 17:09 Uhr schrieb Yaqiang Wang <
yaq...@gm...>:

> Some of the features of Python 3 attract me in this document:
> https://www.asmeurer.com/python3-presentation/python3-presentation.pdf,
> including features 2, 9, 11, 12.
>
> Regards
> Yaqiang
>
> On Sat, Jul 15, 2023 at 8:33 PM John A. Hayes <ja...@gm...> wrote:
>
>> I think the conclusion from all this mail-list activity is there is great
>> interest in a Jython 3.X. Rather than just saying I’m another +1 (which is
>> true), is there a short-list of things that need to be achieved to reach
>> Python 3+ compatibility?
>>
>> In my naive experience as a Python user, the most substantive difference
>> between Python 2+ and Python 3+ was the transition between “print” being a
>> statement in 2 and a function in 3 and that seems trivial. All the other
>> changes were under the hood and not important from a user’s perspective.
>>
>> If there are more corner cases, I’m happy to help,
>>
>> All the best, and I’m a super big fan of the project; it’s just a bit
>> mysterious how any of us can help.
>>
>> John
>>
>> On Jul 15, 2023, at 1:31 AM, Liam Coughlin <lsc...@gm...> wrote:
>>
>> +2 for jython 3 - wait am I doing this right?
>>
>> On Sat, Jul 15, 2023 at 2:13 AM Jon R. Fox <drj...@gm...> wrote:
>>
>>> +1 for Jython 3.x
>>> I'm using Groovy for now.
>>>
>>> _______________________________________________
>>> Jython-users mailing list
>>> Jyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jython-users
>>>
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-users
>>
>>
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-users
>>
>
>
> --
> *************************************************
> Dr. Yaqiang Wang
> Chinese Academy of Meteorological Sciences (CAMS)
> 46, Zhong-Guan-Cun South Avenue
> Beijing, 100081
> China
>
> yaq...@gm...
>
> www.meteothink.org
> **************************************************
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>

Re: [Jython-users] Jython 3?

[Yaqiang W. <yaq...@gm...>]

Some of the features of Python 3 attract me in this document:
https://www.asmeurer.com/python3-presentation/python3-presentation.pdf,
including features 2, 9, 11, 12.

Regards
Yaqiang

On Sat, Jul 15, 2023 at 8:33 PM John A. Hayes <ja...@gm...> wrote:

> I think the conclusion from all this mail-list activity is there is great
> interest in a Jython 3.X. Rather than just saying I’m another +1 (which is
> true), is there a short-list of things that need to be achieved to reach
> Python 3+ compatibility?
>
> In my naive experience as a Python user, the most substantive difference
> between Python 2+ and Python 3+ was the transition between “print” being a
> statement in 2 and a function in 3 and that seems trivial. All the other
> changes were under the hood and not important from a user’s perspective.
>
> If there are more corner cases, I’m happy to help,
>
> All the best, and I’m a super big fan of the project; it’s just a bit
> mysterious how any of us can help.
>
> John
>
> On Jul 15, 2023, at 1:31 AM, Liam Coughlin <lsc...@gm...> wrote:
>
> +2 for jython 3 - wait am I doing this right?
>
> On Sat, Jul 15, 2023 at 2:13 AM Jon R. Fox <drj...@gm...> wrote:
>
>> +1 for Jython 3.x
>> I'm using Groovy for now.
>>
>> _______________________________________________
>> Jython-users mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-users
>>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>


-- 
*************************************************
Dr. Yaqiang Wang
Chinese Academy of Meteorological Sciences (CAMS)
46, Zhong-Guan-Cun South Avenue
Beijing, 100081
China

yaq...@gm...

www.meteothink.org
**************************************************

Re: [Jython-users] Jython 3?

[John A. H. <ja...@gm...>]

I think the conclusion from all this mail-list activity is there is great interest in a Jython 3.X. Rather than just saying I’m another +1 (which is true), is there a short-list of things that need to be achieved to reach Python 3+ compatibility? 

In my naive experience as a Python user, the most substantive difference between Python 2+ and Python 3+ was the transition between “print” being a statement in 2 and a function in 3 and that seems trivial. All the other changes were under the hood and not important from a user’s perspective.

If there are more corner cases, I’m happy to help,

All the best, and I’m a super big fan of the project; it’s just a bit mysterious how any of us can help.

John

> On Jul 15, 2023, at 1:31 AM, Liam Coughlin <lsc...@gm...> wrote:
> 
> +2 for jython 3 - wait am I doing this right?
> 
> On Sat, Jul 15, 2023 at 2:13 AM Jon R. Fox <drj...@gm... <mailto:drj...@gm...>> wrote:
> +1 for Jython 3.x
> I'm using Groovy for now.
> 
> _______________________________________________
> Jython-users mailing list
> Jyt...@li... <mailto:Jyt...@li...>
> https://lists.sourceforge.net/lists/listinfo/jython-users <https://lists.sourceforge.net/lists/listinfo/jython-users>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users

Re: [Jython-users] Jython 3?

[Liam C. <lsc...@gm...>]

+2 for jython 3 - wait am I doing this right?

On Sat, Jul 15, 2023 at 2:13 AM Jon R. Fox <drj...@gm...> wrote:

> +1 for Jython 3.x
> I'm using Groovy for now.
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>

Re: [Jython-users] Jython 3?

[Jon R. F. <drj...@gm...>]

+1 for Jython 3.x
I'm using Groovy for now.

Re: [Jython-users] Jython 3?

[John H. <jhu...@ns...>]

+1 from me too.
--
Cheers
-john


On Fri, Jul 14, 2023 at 11:13 AM Juniarti Suryakusuma via Jython-users <
jyt...@li...> wrote:

> Jython 3 demand + 1
>
> > On Jul 14, 2023, at 2:37 AM, Fernando Cassia <fc...@gm...> wrote:
> >
> > On 14/07/2023, Anamitra Bhattacharyya via Jython-users
> > <jyt...@li...> wrote:
> >> +1 on Jython 3.
> >>
> >> thanks
> >> Anamitra Bhattacharyya
> >> Maximo STSM
> >> IBM Master Inventor
> >
> > +1
> >
> > Cheers,
> > FC
> >
> >
> > _______________________________________________
> > Jython-users mailing list
> > Jyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/jython-users
>
>
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>

Re: [Jython-users] Jython 3?

[Juniarti S. <jun...@ya...>]

Jython 3 demand + 1

> On Jul 14, 2023, at 2:37 AM, Fernando Cassia <fc...@gm...> wrote:
> 
> On 14/07/2023, Anamitra Bhattacharyya via Jython-users
> <jyt...@li...> wrote:
>> +1 on Jython 3.
>> 
>> thanks
>> Anamitra Bhattacharyya
>> Maximo STSM
>> IBM Master Inventor
> 
> +1
> 
> Cheers,
> FC
> 
> 
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users

Re: [Jython-users] Jython 3?

[Fernando C. <fc...@gm...>]

On 14/07/2023, Anamitra Bhattacharyya via Jython-users
<jyt...@li...> wrote:
> +1 on Jython 3.
>
> thanks
> Anamitra Bhattacharyya
> Maximo STSM
> IBM Master Inventor

+1

Cheers,
FC

Re: [Jython-users] Jython 3?

[Anamitra B. <abh...@us...>]

+1 on Jython 3.

thanks
Anamitra Bhattacharyya
Maximo STSM
IBM Master Inventor
________________________________
From: Yaqiang Wang <yaq...@gm...>
Sent: Thursday, July 13, 2023 8:02 PM
To: Jeff Allen <ja...@fa...>
Cc: jyt...@li... <jyt...@li...>
Subject: [EXTERNAL] Re: [Jython-users] Jython 3?

Jython 3 demand + 1. Regards Yaqiang On Thu, Jul 13, 2023 at 4: 56 PM Jeff Allen <ja. py@ farowl. co. uk> wrote: Not soon. We can't put a date to it, but we continue to have Jython 3 as a goal. It is good to hear there is still a demand. 
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJA3gVI0Ny5x94Btbklmwjn44fZaF_FPdEgLCAndaDB_wqDxWMfY6-o9MKubYrVogwKMmpBOUJWZVkUg97JuuaWjrXa9VvrWZiaEXX0pTWP8cq1yV5nx2Vnr7uoz$>
Report Suspicious

ZjQcmQRYFpfptBannerEnd
Jython 3 demand + 1.

Regards
Yaqiang

On Thu, Jul 13, 2023 at 4:56 PM Jeff Allen <ja...@fa...<mailto:ja...@fa...>> wrote:

Not soon. We can't put a date to it, but we continue to have Jython 3 as a goal.

It is good to hear there is still a demand.

On 07/07/2023 19:53, Shellman, Spencer D. (Contractor) via Jython-users wrote:

Hi,



Can I expect Jython 3.* anytime soon?  This would be extremely useful to me.  Thanks.


--

Jeff Allen


_______________________________________________
Jython-users mailing list
Jyt...@li...<mailto:Jyt...@li...>
https://lists.sourceforge.net/lists/listinfo/jython-users<https://lists.sourceforge.net/lists/listinfo/jython-users>


--
*************************************************
Dr. Yaqiang Wang
Chinese Academy of Meteorological Sciences (CAMS)
46, Zhong-Guan-Cun South Avenue
Beijing, 100081
China
　　　　　　　　　　　　　
yaq...@gm...<mailto:yaq...@gm...>

www.meteothink.org<http://www.meteothink.org>
**************************************************

Re: [Jython-users] Jython 3?

[Yaqiang W. <yaq...@gm...>]

Jython 3 demand + 1.

Regards
Yaqiang

On Thu, Jul 13, 2023 at 4:56 PM Jeff Allen <ja...@fa...> wrote:

> Not soon. We can't put a date to it, but we continue to have Jython 3 as a
> goal.
>
> It is good to hear there is still a demand.
> On 07/07/2023 19:53, Shellman, Spencer D. (Contractor) via Jython-users
> wrote:
>
> Hi,
>
>
>
> Can I expect Jython 3.* anytime soon?  This would be extremely useful to
> me.  Thanks.
>
> --
>
> Jeff Allen
>
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-users
>


-- 
*************************************************
Dr. Yaqiang Wang
Chinese Academy of Meteorological Sciences (CAMS)
46, Zhong-Guan-Cun South Avenue
Beijing, 100081
China

yaq...@gm...

www.meteothink.org
**************************************************

Re: [Jython-users] Jython 3?

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

Not soon. We can't put a date to it, but we continue to have Jython 3 as 
a goal.

It is good to hear there is still a demand.

On 07/07/2023 19:53, Shellman, Spencer D. (Contractor) via Jython-users 
wrote:
>
> Hi,
>
> Can I expect Jython 3.* anytime soon?  This would be extremely useful 
> to me.  Thanks.
>
>
-- 

Jeff Allen

[Jython-users] Jython 3?

[Shellman, S. D. (Contractor) <Spe...@un...>]

Hi,

Can I expect Jython 3.* anytime soon?  This would be extremely useful to me.  Thanks.