On Fri, Oct 19, 2018 at 6:23 PM, Marten van Kerkwijk
wrote:
> Hi All,
>
> It seems there are two extreme possibilities for general functions:
> 1. Put `asarray` everywhere. The main benefit that I can see is that even if
> people put in list instead of arrays, one is guaranteed to have shape,
> dt
On Fri, Oct 19, 2018 at 7:00 PM, Charles R Harris
wrote:
>
> On Fri, Oct 19, 2018 at 7:50 PM Eric Wieser
> wrote:
>>
>> Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
>> they cause problems perhaps that should be seen as a sign that ndarray
>> subclassing should be mad
On Fri, Oct 19, 2018 at 7:50 PM Eric Wieser
wrote:
> Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
> they cause problems perhaps that should be seen as a sign that ndarray
> subclassing should be made easier and clearer.
>
> Both maskedarray and quantity seem like som
Subclasses such as MaskedArray and, yes, Quantity, are widely used, and if
they cause problems perhaps that should be seen as a sign that ndarray
subclassing should be made easier and clearer.
Both maskedarray and quantity seem like something that would make more
sense at the dtype level if our dt
Hi All,
It seems there are two extreme possibilities for general functions:
1. Put `asarray` everywhere. The main benefit that I can see is that even
if people put in list instead of arrays, one is guaranteed to have shape,
dtype, etc. But it seems a bit like calling `int` on everything that might
On Fri, Oct 19, 2018 at 10:28 PM Ralf Gommers
wrote:
>
>
> On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
> wrote:
>
>> Hi!
>>
>> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
>> wrote:
>> I don't think it makes much sense to change NumPy's existing usage of
>> asarray() to asanyarray() unle
>
> I think we should “soft support” i.e. allow but consider unsupported, the
>> case where one of NumPy’s functions is implemented in terms of others and
>> “passing through” an array results in the correct behaviour for that array.
>>
>
> I don't think we have or want such a concept as "soft supp
On Fri, Oct 19, 2018 at 3:28 PM, Ralf Gommers
wrote:
>
>
> On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
> wrote:
>
>> Hi!
>>
>> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
>> wrote:
>> I don't think it makes much sense to change NumPy's existing usage of
>> asarray() to asanyarray() unle
On Fri, Oct 19, 2018 at 4:15 PM Hameer Abbasi
wrote:
> Hi!
>
> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer
> wrote:
> I don't think it makes much sense to change NumPy's existing usage of
> asarray() to asanyarray() unless we add subok=True arguments (which default
> to False). But this en
On Fri, Oct 19, 2018 at 4:49 PM Stephan Hoyer wrote:
>
>
> On Fri, Oct 19, 2018 at 2:22 AM Sebastian Berg
> wrote:
>
>> On Fri, 2018-10-19 at 11:02 +0300, Matti Picus wrote:
>> > We currently have highest, high, normal, low, and lowest priority
>> > labels
>> > for github issues/PRs. At the rece
On Fri, Oct 19, 2018 at 2:22 AM Sebastian Berg
wrote:
> On Fri, 2018-10-19 at 11:02 +0300, Matti Picus wrote:
> > We currently have highest, high, normal, low, and lowest priority
> > labels
> > for github issues/PRs. At the recent status meeting, we proposed
> > consolidating these to a single "
Hi!
> On Friday, Oct 19, 2018 at 6:09 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote:
> I don't think it makes much sense to change NumPy's existing usage of
> asarray() to asanyarray() unless we add subok=True arguments (which default
> to False). But this ends up cluttering NumPy's public
I don't think it makes much sense to change NumPy's existing usage of
asarray() to asanyarray() unless we add subok=True arguments (which default
to False). But this ends up cluttering NumPy's public API, which is also
undesirable. The preferred way to override NumPy functions going forward
should
There are exceptions for `matrix` in quite a few places, and there now is
warning for `maxtrix` - it might not be bad to use `asanyarray` and add an
exception for `maxtrix`. Indeed, I quite like the suggestion by Eric Wieser
to just add the exception to `asanyarray` itself - that way when matrix is
On Fri, 2018-10-19 at 11:02 +0300, Matti Picus wrote:
> We currently have highest, high, normal, low, and lowest priority
> labels
> for github issues/PRs. At the recent status meeting, we proposed
> consolidating these to a single "high" priority label. Anything
> "low"
> priority should be mer
Hi all
> On Friday, Oct 19, 2018 at 10:28 AM, Matti Picus (mailto:matti.pi...@gmail.com)> wrote:
>
> Was there discussion around which of `asarray` or asanyarray` to prefer? PR
> 11162, https://github.com/numpy/numpy/pull/11162, proposes `asanyarray` in
> place of `asarray` at the entrance to `
Was there discussion around which of `asarray` or asanyarray` to
prefer? PR 11162, https://github.com/numpy/numpy/pull/11162,
proposes `asanyarray` in place of `asarray` at the entrance to `_quantile_ureduce_func` to preserve ndarray
subclasses. Should we be looking
We currently have highest, high, normal, low, and lowest priority labels
for github issues/PRs. At the recent status meeting, we proposed
consolidating these to a single "high" priority label. Anything "low"
priority should be merged or closed since it will be quickly forgotten,
and no "normal"
18 matches
Mail list logo
