Re: [Jython-dev] Jython 3: greenhorn questions from an old hand

[<fwi...@gm...>]

On Mon, May 29, 2017 at 3:07 AM, Jeff Allen <ja...@fa...> wrote:
> With 2.7.1 seemingly on its release journey, I have a bit of time to hack on
> Jython 3.  A lot has been done to Jython 3 since it forked from 2, so I have
> some really newbie questions:
>
>  * Is https://github.com/jython/jython3 the official reference
>    repository? (Is https://hg.python.org/sandbox/jython3 dead?)
Yes, the github repo is the right one to look at. In the beginning of
Isaiah Peng's amazing contributions, I reviewed his commits carefully.
Things where improving so much so fast that I just let them go after a
while. I'm sure there will be some places where we will want to adjust
things. I know there are some commits in there for convenience that I
wouldn't want pulled over as is (for example src/com/ziclix/ and
src/org/python/indexer/ where removed - I'd prefer that we move them
to their own directories like we do with installer/. In the case of
ziclix, I'd like to eventually replace those with
https://bitbucket.org/clach04/jyjdbc/ but it isn't a full replacement
yet (I have permission from the author, my fault that it isn't in
yet).

>  * Are we still building with Ant? (It didn't for me on Windows, and I
>    thought I'd fix that first.) BTW, this is a question about now, not
>    what we'd like to do in future.
Yes, we are still on ant for Jython3

>  * Versions: Java 8, and Python 3.5?
I'm for aggressively using the latest Java for Jython3, pretty much
whatever is the latest when we actually release. Given how big of a
task this will be, I'm sure that will be at least Java 9 in the end
:). I'm pretty sure the current Jython3 is focused on 3.5, but I'd be
fine with pointing to 3.6. Once we are serious about Jython3, we
probably should pick a version and see it through, as it definitely
takes more work to switch Python versions vs Java versions.

>  * Although I believe I could commit directly to
>    https://github.com/jython/jython3, or a branch in there, do we agree
>    a better practice is to fork, branch and create a PR for a "feature"
>    (groups of related commits)? Even if I then accept my own PR, it
>    seems to give us a better audit trail, integration test, squash
>    point, etc.. A separate thread/discussion is due about workflow,
>    naming, etc..
That sounds good to me. I haven't studied CPython's workflow for
github, but in general I think we should try to do what they do.

>  * Do we agree that our aim is to run the CPython regression tests with
>    as few skips, exclusions and replacement tests as possible?
Yes, and one of my dream projects is to get as many of our changes
into CPython's standard lib as possible, with an ultimate goal of
removing our own Lib/ directory altogether.

>  * Does anyone have code stored up that I risk duplicating? (E.g.
>    Somewhere, Darjus mentioned ANTLR4 migration.) Otherwise I'll just
>    start with things I know about (bytes and strings, buffer interface,
>    io, import perhaps), driven by getting Py3k tests to pass honestly.
Not me :)

>
> I will averaging much fewer than 3 commits a day. ;)
>
> --
>
> 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