Re: Ascent of Jython 3
Jeff Allen <[email protected]>
| Newsgroups | gmane.comp.lang.jython.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Stefan:
If the tests are not a good driver for us, I think it follows we need to
start with Java unit tests of implementation-level features. There are
some in the code base, but of course they need updating to 3.
With regard to this:
"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."
The idea of revisiting the dev guide was to adopt the CPython flow for
Jython. I think it can work to use it for Jython 3 while we continue to
use our old flow for Jython 2. I was trying that in the sand box. But
only for a time, as we need to move out of hg.python.org so as not to be
a support burden. I was tentatively thinking we might do that when 2.7.2
releases. I'd like to see us adopt the tools CPython have created
(bedevere, knight-who-say-ni, etc. as needed).
For CPython, issues are on the traditional tracker. (Their devguide
issues & contribution process is fully based in GitHub.) As we have no
Jython 3 bugs on our tracker, we could perhaps start as we mean to go on.
This is suddenly exciting again.
Jeff
Adam: impressed by your metadata "在 2017年11月24日，上午9:44" etc.. I hope
this means you're testing our Unicode support!
Jeff Allen
On 24/11/2017 16:24, Stefan Richthofer wrote:
> 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]
> <mailto:[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
> <http://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]
> <mailto:[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
> <http://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://Slashdot.org>!
> http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> [email protected]
> <mailto:[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://Slashdot.org>!
> http://sdm.link/slashdot
>
> _______________________________________________
> Jython-dev mailing list
> [email protected]
> <mailto:[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