Re: [Jython-dev] Ascent of Jython 3

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

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 <jim...@py...> 写道：
> 
> 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 <ja...@fa...> 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
>> 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