[Cython] some pull requests for 0.16?

[mark florisson]

On 22 March 2012 07:18, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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.
>

Mostly the pull requests and this reversed bug
(http://trac.cython.org/cython_trac/ticket/763), which I marked as a
blocker. As much as I would like to push stuff out early, I really
find it more important to push something that is as stable and useful
as possible, even if it delays a release by a couple of weeks.

I'll make a release branch, a clone of the current master, but I want
several other things in there as well:
    1) Dag's pull request for the portable attribute access of
np.ndarray (I think this is important as np.ndarray is commonly used
and in future numpy versions the attributes might be removed
altogether)
    2) Runtime dispatch for buffers for fused types. This would make
fused types much more useable and useful for many people. It's nearly
finished, I just need to add a few more tests and test on Jenkins

Basically until Jenkins is up and everything is tested there, we
shouldn't push anything into the release branch.

>>>>> 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.

It would be easy to disable. Personally I'd like to give the people at
PyCon who where interested in sprinting with us the chance to finish
what they were working on, in this case Mike Graham, who indicated
that he means to finish his work on the bug (and add proper tests for
them). I think we shouldn't pull work out of people's hands, but
instead encourage them to work on Cython and possibly contribute in
the future.

> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel