Issue2146

This patch is to bring xrange's iterator to par with CPython's implementation and to pass a previously failing test in lib-python/2.7/test/test_enumerate.py re: xrange iterator.

Will review for beta 4

Fixed as of http://hg.python.org/jython/rev/33ab610967ec

@zyasoft You forgot to also merge/check in `PyXRangeIter.java` here. Won't compile without it.

Just pushed the missing file.

I am not able to extract out usable changesets due to how the history in your santa4nt fork is interacting with what is hg.python.org/jython

You may want to switch to a feature fork process so we can merge Mercurial changesets instead of diffs. Changesets do have the advantage they retain changes to file layout, such as adding/removing files, so at least we wouldn't see this missing file in a commit issue.

Such forks are much more heavyweight, but they seem to work. If you do switch to this process, do not use a named branch/bookmark in such forks, this will cause issues at merge into hg.python.org/jython, and perhaps even more opportunities for painful merging, something I saw when I tried to merge my socket-reboot fork (although I know how to fix this issue if it comes up) ;)

@zyasoft, so, just nameless heads?

@zyasoft Oh, are you saying I should fork a clone for each fix/feature I'm  issuing a PR for?

That would be easier to work with on my end, but just marginally so. It's up to you -  a missing committed file is rare and easy to spot with any level of testing. However, it should mean we could merge in the changesets of the PRs, and bitbucket should be able to detect this and mark the PR as merged. Should. I have seen bitbucket in fact not do this. But after all, https://bitbucket.org/jython/jython is a mirror, so that it even sort of works is perhaps the real thing we should appreciate! ;)

The lack of any CI on PRs is a bigger issue; that we are running PRs on bitbucket means it requires more integration work.

I think we need to revisit this whole process post 2.7.0, possibly using github and travis CI to frontend hg.python.org/jython, given that it's just a final push anyway and we are not using any of the branch support at hg.python.org other than for 2.7 vs 2.5 - it's just too heavyweight/error prone. Even better workflows as seen in OpenStack would be fantastic.

CPython is looking at a completely revamped workflow, but it's very early in the planning process: https://mail.python.org/pipermail/core-workflow/

I see. I'm not privy to how pull requests are handled on that side. I was
under the impression that Bitbucket could detect __only__ the changes
between the head of https://bitbucket.org/jython/jython and the head of
whatever branch I sent a pull request for, as I took care that said branch
is always isolated to the feature/issue at hand. The bookmarks are there
for me to keep track of different heads in one repo, but they are all their
own feature "branches" per se.

~/santoso

On Mon, Jun 23, 2014 at 8:40 AM, Jim Baker <report@bugs.jython.org> wrote:

>
> Jim Baker added the comment:
>
> That would be easier to work with on my end, but just marginally so. It's
> up to you -  a missing committed file is rare and easy to spot with any
> level of testing. However, it should mean we could merge in the changesets
> of the PRs, and bitbucket should be able to detect this and mark the PR as
> merged. Should. I have seen bitbucket in fact not do this. But after all,
> https://bitbucket.org/jython/jython is a mirror, so that it even sort of
> works is perhaps the real thing we should appreciate! ;)
>
> The lack of any CI on PRs is a bigger issue; that we are running PRs on
> bitbucket means it requires more integration work.
>
> I think we need to revisit this whole process post 2.7.0, possibly using
> github and travis CI to frontend hg.python.org/jython, given that it's
> just a final push anyway and we are not using any of the branch support at
> hg.python.org other than for 2.7 vs 2.5 - it's just too heavyweight/error
> prone. Even better workflows as seen in OpenStack would be fantastic.
>
> CPython is looking at a completely revamped workflow, but it's very early
> in the planning process: https://mail.python.org/pipermail/core-workflow/
>
> _______________________________________
> Jython tracker <report@bugs.jython.org>
> <http://bugs.jython.org/issue2146>
> _______________________________________
>

I see. I'm not privy to how pull requests are handled on that side. I was under the impression that Bitbucket could detect __only__ the changes between the head of https://bitbucket.org/jython/jython and the head of whatever branch I sent a pull request for, as I took care that said branch is always isolated to the feature/issue at hand. The bookmarks are there for me to keep track of different heads in one repo, but they are all their own feature "branches" per se.

Oops, doublepost.

Feel free to choose the method of your choice, but this is just the limitation I have identified with our bitbucket setup.

At the end of the day, I have found this API to be sufficiently robust to get the necessary diff, regardless of how the PR has been built:
https://bitbucket.org/api/2.0/repositories/jython/jython/pullrequests/38/diff

Simply vary the PR number as necessary