[Cython] some pull requests for 0.16?

[Stefan Behnel]

Robert Bradshaw, 21.03.2012 21:24:
> On Wed, Mar 21, 2012 at 6:47 AM, mark florisson wrote:
>> On 20 March 2012 18:51, Stefan Behnel wrote:
>>> mark florisson, 20.03.2012 17:40:
>>>> On 18 March 2012 11:58, Stefan Behnel wrote:
>>>>> I put up two new pull requests on github:
>>>>>
>>>>> Implementation of PEP 380 (yield from):
>>>>> https://github.com/cython/cython/pull/96
>>>>>
>>>>> Rewrite of dict iteration:
>>>>> https://github.com/cython/cython/pull/95
>>>>>
>>>>> Given that the release of 0.16 has currently slowed down a bit, and given
>>>>> that these are really nice features, could someone (and especially Mark, as
>>>>> the responsible release manager) take a look at them and give an opinion
>>>>> regarding their suitability for 0.16?
>>>>
>>>> Sorry about the slowdown, my BT internet connection at home got closed
>>>> off, so working on a release is rather hard, hopefully that will be
>>>> fixed within the next few days.
> 
> Thanks for the status update. Is there a separate release branch, or
> are you working off the github master?

Not currently. I also agree that we should try to get out the release soon.
What about this: I merge my pending pull requests, we test everything in
Sage (it's been normally tested in my dev branch already), and if that
doesn't break anything, we release another beta? If it does break anything,
it's either easy enough to fix, or we can create a release branch at that
point with the status before the merges.

sage.math seems to be back up, although the /levi drive isn't. If there are
no objections, I'll make sure Jenkins gets back up and then do the above.


> Is there a list of issues/blockers somewhere?

Don't know.


>>>> Finally, there is a serious bug in the reversed(range()) optimization
>>>> that Mike Graham discovered when working on the range() optimization
>>>> with a runtime step, which is basically wrong for any step that is not
>>>> 1 or -1 (it simply swaps the bounds with an offset by 1, but it
>>>> actually has to figure out what the actual last value was in the range
>>>> and use that as the start instead). I personally consider this a
>>>> blocker, so I'll try contacting Mike and see if he is still
>>>> (interested in) working on that.
>>>
>>> Interesting. Yes, I can well imagine that being wrong. These things are
>>> exceedingly tricky.
>>>
>>> However, it's easy to disable the optimisation for a specific case - likely
>>> easier than fixing it.
>>>
>>> Also, I don't consider this a blocker. It's not like it works in the
>>> current release, so it's not a regression compared to that.
>>
>> Yes, it's not a regression, but I find it hard to release something
>> that is so broken, and I feel it kind of represents a lack of care
>> which may make people believe Cython can't be taken seriously.
> 
> I'm usually in the "not a regression" camp as well, but this is pretty
> fundamental. Sounds like an easy fix, or at least an easy-to-disable
> optimization.

I'll take a look - maybe not before the weekend though.

Stefan