Re: Ascent of Jython 3

I think it should ideally be something like langauage-wise (syntax, bytecode, import mechanism, other things like that) target 3.7, API and library wise target a subset first, maybe 3.5 (leaving out modules deprecated or vastly refractured in 3.6 or 3.7).

> Or are they all only useful once Jython 3 works 80%?

That's what I mean by a roadmp. I think there are some major changes from 2.7 to 3.5 that should be implemented before reasonable testing and test-driven development can start. I just don't know exactly what those are (besides replacing PyString by PyUnicode and getting rid of old-style classes). But I'm sure these can be looked up somewhere in the Python resources.

Regarding git, I'd use its features to export and import commits as diff-files. I'd fork Jython 2.7 on github, so that new commits can be pulled from there. Then I'd clone Jython 3 sandbox and export all commits after it diverged from 2.7 branch to diff files. And then somehow work through them. Apply one by one, solve conflicts and run tests or at least assert runnability.

It's a lot of work, but it has to get started somehow.

For the official Jython 3 repository, it's probably best to switch to CPython workflow.

The switch from Jython 2.7 to 3 is IMHO the ideal opportunity to switch the workflow as well. Given our limited resources I would recommend not to spend time on migrating Jython 2.7 workflow to CPython.

Gesendet: Freitag, 24. November 2017 um 14:06 Uhr

Von: "Adam Burke" <[email protected]>

An: Kein Empfänger

Cc: "Jython Developers" <[email protected]>

Betreff: Re: [Jython-dev] Ascent of Jython 3

From the sidelines:

Are there any meaningful subsets of 3.7 features / testpack which could make usable intermediate milestones?

Cheers

Adam

在 2017年11月24日，上午9:44，Jim Baker <[email protected] > 写道：

I like the idea of starting from 2.7.2, and reaching back to the jython3 sandbox as it makes sense. One logical commit, followed by another, with tests passing as we converge on 3.7 (I assume it's easier to just target that version). The biggest immediate challenge will probably be around importlib logic, this is what is failing in the sandbox when I last looked at it.

I suggest we do all of this in GitHub, under let's say a 3.7 branch of github.com/jython/jython . We can start by stripping out binaries - the jython.exe and everything in extlibs/ It's easy enough to retrieve from maven the necessary libraries, and it would be much better to have this be anything but something hardcoded going forward.

On Thu, Nov 23, 2017 at 4:34 PM, Jeff Allen <[email protected] > wrote:

(Starting a new thread for this.)

Stefan:

It is a good reminder that the repository in question is described as a "sandbox". It's largely un-reviewed work, outside the official repository. However, there's quite a lot of sand in the box.

What you propose sounds good to me. So the idea is a branch from Jython 2.7.2. I am visualising this in GitHub. Do you imagine we would have moved 2.7 work to GitHub first? Or does the plan work while we are still mastered at hg.python.org and feeding a 2.7 branch that way?

I couldn't imagine the mechanics when first I considered it, but have more knowledge of git now. The fusing of our dev guide back into a fork of the CPython dev guide is perhaps a microcosm and was good training.

All the work I've done on Jython has been driven by Python regression tests, although the proportion of failures has always been fairly small. Do you think it would work to begin by adding the tests for Python 3.7 (or maybe aim a little lower), and repeatedly throwing ourselves at that rock face? The tests of course would fail massively at first. Or are they all only useful once Jython 3 works 80%?

As when we discussed this previously, though, I'm unable to imagine an automated process for merging change, unless "automated" encompasses long hours spent with KDiff3. When you've nearly-bulk replaced PyString with PyUnicode, for example, how is *any* merge going to run smoothly?

Jeff

On 23/11/2017 19:01, Stefan Richthofer wrote:

> Merging means pulling from 2.7 to 3, I think.

I'm actually going to try it the other way round.

The current situation with Jython 3 concerns me a bit. It seems to

be in a state where it is unclear how to proceed. This makes it

somewhat discouraging to work on it. So I think we need a proper

plan how to go on. I'd suggest the following:

We open a new fresh Jython 3 that starts at Jython 2.7.2 release.

Keep in mind that the Jython 3 repository is actually a *sandbox*

so far. We merge every commit done to Jython 3 sandbox since it

was forked from 2.7, (hopefully mainly via automatic merge

mechanism). This is the ideal opportunity to triage the issue

with broken Windows support and to review Isaiahs work. While

he did a lot great work on Jython 3 we must keep in mind that it

has been hardly reviewed so far.

I hope we can end up with a workable Jython 3 containing all the

bugfixes and improvements that were added in Jython 2.7.1 and 2.

Problematic commits can be sorted out for later additional review.

Regarding some aspects I propose to directly target Python 3.7, e.g.

bytecode level and language syntax. Going through intermediate

versions would be multiple work here.

Besides this merging work we will need a real roadmap that states

all the milestones and steps required for a Jython 3 release. Who

of us knows Python well enough to put this together? Jim? Frank?

After merging is done we need a clear policy about backporting etc.

I'd suggest to focus on Jython 3 then and only backport crucial or

cherry-picked bugfixed to 2.7 branch.

In the sprint I'll start an inofficial experimental Jython 3 to work on merging.

This can maybe form the basis for an official non-sandbox Jython 3.

Thoughts?

-Stefan

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

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

[email protected]

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

[email protected]

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 [email protected] 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev