> Thoughts on how to proceed are welcome.
I've been involved in scikit-image and that project tore out the python2
only code rather quickly after 2.7 support was dropped. I think it caused a
few hiccups when backporting bugfixes. I imagine that `1.16.1` and `1.16.2`
releases will come out quickly
I was wondering what would your thoughts be on adding an output parameter
to np.fromfile?
The advantage would be when interfacing with executables like ffmpeg which
are arguably easier to use by calling them as a subprocess compared to a
shared library in python.
Having the output parameter in np
On Sun, Nov 4, 2018 at 6:16 PM Stephan Hoyer wrote:
> On Sun, Nov 4, 2018 at 10:32 AM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> Hi Chuck,
>>
>> For `__array_function__`, there was some discussion in
>> https://github.com/numpy/numpy/issues/12225 that for 1.16 we might want
>>
On Sun, Nov 4, 2018 at 8:45 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Does the above make sense? I realize that the same would be true for
> `__array_ufunc__`, though there the situation is slightly trickier since it
> is not as easy to bypass any further override checks. Nevert
On Sun, Nov 4, 2018 at 10:32 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Chuck,
>
> For `__array_function__`, there was some discussion in
> https://github.com/numpy/numpy/issues/12225 that for 1.16 we might want
> to follow after all Nathaniel's suggestion of using an environm
On Sun, Nov 4, 2018 at 8:03 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> I thought of this partially as I was wondering how an implementation for
> ndarray itself would look like. For that, it is definitely useful to know
> all unique types, since if it is only ndarray, no casting
On 4/11/18 8:04 pm, Charles R Harris wrote:
Hi All,
Time to begin looking forward to the NumPy 1.16.x branch. I think
there are three main topics to address:
1. current PRs that need review and merging,
2. critical fixes that need to be made,
3. status of `__array_function__`.
The last
Hi Chuck,
For `__array_function__`, there was some discussion in
https://github.com/numpy/numpy/issues/12225 that for 1.16 we might want to
follow after all Nathaniel's suggestion of using an environment variable or
so to opt in (since introspection breaks on python2 with our wrapped
implementatio
Hi All,
Time to begin looking forward to the NumPy 1.16.x branch. I think there are
three main topics to address:
1. current PRs that need review and merging,
2. critical fixes that need to be made,
3. status of `__array_function__`.
The last probably needs some discussion. `__array_fu
Hi All,
On behalf of the NumPy team, I am pleased to announce the release of NumPy
1.15.4. This is a bugfix release for bugs and regressions reported
following the 1.15.3 release. The most noticeable fix is probably having a
boolean type fill value for masked arrays after the use of `==` and `!=`
Hi again,
Another thought about __array_function__, this time about the
implementation for ndarray. In it, we currently check whether any of the
types define a (different) __array_function__, and, if so, give up. This
seems too strict: I think that, at least in principle, subclasses should be
allo
Hi All,
While thinking about implementations using __array_function__, I wondered
whether the "types" argument passed on is not defined too narrowly.
Currently, it only contains the types of arguments that provide
__array_ufunc__, but wouldn't it make more sense to provide the unique
types of all
12 matches
Mail list logo
