Re: [Numpy-discussion] [REL] Matplotlib 3.0.0

[Thomas Caswell]

Folks,

A small update, when I uploaded the wheels yesterday I only uploaded about
half of them [1] and did not check my work carefully enough.  This has been
rectified, sorry to everyone who had installs fail his morning.

Tom

[1] I downoladed one of the wheels from http://wheels.scipy.org/ twice, the
browser helpfully added (1) to the name, when I when to upload everything
twine got half way through and failed out on that file.  I thought it had
done everything else, but it had actually only done everything up to that
file.

On Tue, Sep 18, 2018 at 8:43 PM Thomas Caswell  wrote:

> Folks,
>
> Happy to announce Matplotlib 3.0.0!
>
> This is the first version of Matplotlib to only support Python 3.
>
> If you need Python 2.7 support the 2.2.x LTS series will continue to
> receive critical bug-fixes until 2020.
>
> Highlights of this release include:
>
>  - GUI backend is selected at run-time based on what toolkits are
>installed.  A GUI toolkit will not be selected on a headless
>server.
>  - New cyclic color map *twilight*
>  - Improvements to automatic layout of titles, ticks, and GridSpec
>  - Many bug fixes!
>
> For the full details see  https://matplotlib.org/users/whats_new.html
> and  https://matplotlib.org/api/api_changes.html for whats new and API
> changes respectively.
>
> For packagers: Matplotlib no longer depends on six or pytz.
>
> A big thank you to everyone who worked on this release in terms of commits
> (~130 people have commits), reporting issues, and review.
>
> I expect there to be a v3.0.1 release in the next month or so.
>
> Tom
>
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.15.2

[Charles R Harris]

Hi All,

I'm planning to make a NumPy 1.15.2 release this coming weekend in order to
deal with a couple of bugs. The fixes queued up for the release can be seen
here
.
If you think that there should be addition, please comment.

Cheers,

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

[Stephan Hoyer]

On Thu, Sep 13, 2018 at 10:30 AM Stephan Hoyer  wrote:

> On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris 
> wrote:
>
>> On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer  wrote:
>>
>>> I propose to accept NEP-18, "A dispatch mechanism for NumPy’s high level
>>> array functions":
>>> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>>>
>>> Since the last round of discussion, we added a new section on "Callable
>>> objects generated at runtime" clarifying that to handle such objects is out
>>> of scope for the initial proposal in the NEP.
>>>
>>> If there are no substantive objections within 7 days from this email,
>>> then the NEP will be accepted; see NEP 0 for more details.
>>>
>>>
>> I've merged the PR. What next?
>>
>> Chuck
>>
>
> I rolled back Chuck's merge of the "Acceptance" PR for this NEP because
> (1) it was not clear that if had reached consensus and (2) I still wanted
> to make a few changes based on this discussion.
>
> I have now drafted these revisions to the NEP to clarify its stance around
> backwards compatibility, and the type of the "types" argument:
> https://github.com/numpy/numpy/pull/11943
>
> I have *not* included any form of the explicit "end-user opt-in" requested
> by Nathaniel. I don't think it is warranted based on the scope of
> anticipated future changes; see my earlier post [1] for details. Nobody has
> seriously suggested that we would release this functionality and later
> eliminate the ability to override NumPy functions entirely in the future.
>
> Of course, requiring an onerous explicit opt-in would be fine while this
> feature is initially under development, and until we are sure that checks
> for overriding arbitrary NumPy functions are fast enough to be generally
> viable. In particular, we should verify that __array_function__ does not
> meaningfully impact performance for major downstream components of the
> SciPy stack. But I think running standard benchmark suites (e.g., with ASV)
> and user testing of release candidates would be enough.
>
> If you have still have major objections to this version of proposal,
> please raise them unambiguously -- preferably with an formal veto [2].
>

Again, if anyone (yes, I'm looking at you, Nathaniel!) still has objections
please speak up soon.

If I don't hear anything, I'm going submit a PR to mark this proposal as
"Accepted" tomorrow (one week after these latest revisions).

As Chuck noted, "Tentatively accepted" or "Experimental" would probably be
a better status, but that currently isn't one of our options for NEPs. In
any case, I would love to move on from debate to implementation!

As a side note, I recently noticed a CuPy pull request (
https://github.com/cupy/cupy/pull/1650
) to add __array_function__.
It's a testament to our proposed interface that the full PR is 9 lines of
code without tests.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion