[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

On Tue, 7 May 2024, at 7:04 AM, Ralf Gommers wrote: > This problem could have been avoided by proper use of upper bounds. > Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug in > scikit-image (definitely for ABI reasons, and arguably also for API reasons). > It would really be

[Numpy-discussion] Re: Function that searches arrays for the first element that satisfies a condition

his is only recommended for sourcing functions that are not called > frequently, but rather have a large computational content within them. In > other words not suitable for predicates. > > Regards, > DG > >> On 1 Nov 2023, at 01:05, Juan Nunez-Iglesias wrote: >> >>

[Numpy-discussion] Re: Function that searches arrays for the first element that satisfies a condition

If you add a layer of indirection with Numba you can get a *very* nice API: @numba.njit def _first(arr, pred): for i, elem in enumerate(arr): if pred(elem): return i def first(arr, pred): _pred = numba.njit(pred) return _first(arr, _pred) This even works with

[Numpy-discussion] Re: Change in numpy.percentile

On Mon, 9 Oct 2023, at 7:07 PM, Andrew Nelson wrote: > On Mon, 9 Oct 2023 at 16:36, Jerome Kieffer wrote: > I'd be ambivalent on making this change. THere are a whole host of other > `np.nan*` functions, would they all need to be modified as well? e.g. > nanprod, nansum, nanargmin, .. I

[Numpy-discussion] Re: Add to NumPy a function to compute cumulative sums from 0.

I'm very sensitive to the issues of adding to the already bloated numpy API, but I would definitely find use in this function. I literally made this error (thinking that the first element of cumsum should be 0) just a couple of days ago! What are the plans for the "extended" NumPy API after

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

On Wed, 31 May 2023, at 4:11 PM, Juan Nunez-Iglesias wrote: > For me it is indeed too surprising, and I would be in favour of reverting. ( Incidentally I wrote that before seeing https://github.com/scikit-image/scikit-image/pull/6970 ) > On Wed, 31 May 2023, at 3:55 PM, Sebastian Berg

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

For me it is indeed too surprising, and I would be in favour of reverting. On Wed, 31 May 2023, at 3:55 PM, Sebastian Berg wrote: > Hi all, > > there was recently a PR to NumPy to improve the performance of sin/cos > on most platforms (on my laptop it seems to be about 5x on simple > inputs). >

[Numpy-discussion] Re: Categorical dtypes

Thanks for the response, Sebastian! I'll keep an eye out on that repo. Should there be (is there already) a link to it from the docs? On Tue, 30 May 2023, at 6:21 PM, Sebastian Berg wrote: > On Mon, 2023-05-29 at 10:55 +1000, Juan Nunez-Iglesias wrote: >> Hi folks, >>

[Numpy-discussion] Categorical dtypes

Hi folks, Apologies if this is documented somewhere, but I haven't been able to find it. I've read through NEP-42 [1] and skimmed NEP-41 [2], but I'm not sure: (a) at what point of implementation we are, and (b) if it's pretty much done, *how* to define a custom categorical dtype. In my use

[Numpy-discussion] Re: Software Freedom Conservancy calls for move from Github

Thanks Matthew! I will say one thing, I agree that there are major costs, but the longer I work in this space the more I appreciate the benefits there might be to *not* being on GitHub. I recently (finally) read Nadia Eghbal's Working in Public, where she points out that *adding* friction to

[Numpy-discussion] Re: NEP 50: Promotion rules for Python scalars

> For example, in NumPy: > >np.median(np.float32([1, 2, 3, 4])) > > did return a float64 before and will now return a float32. I assume > because somewhere we write: `(np.float64(3) + np.float32(2)) / 2`. Sorry, I missed this part of the discussion — I know the discussion centered around

[Numpy-discussion] Re: Automatic formatters for only changed lines

On Sun, 8 May 2022, at 7:11 AM, Sebastian Berg wrote: > To be fair to black, the main issue there is the trailing `,` which > forces items to be formatted on a line each (yapf does the same). > If you remove the trailing comma, you will get close to what you want > also in black: > >

[Numpy-discussion] Re: Automatic formatters for only changed lines

With the caveat that I am just an interested bystander, I would like to point back to yapf as an alternative. I agree with what has already been echoed by the majority of the community, that setting *some* auto-formatter is a huge benefit for both review and writing sanity. I very much disagree

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

> * e.g. the same user might initially be happy about the result of x[0] + 1 > matching their infinite-precision expectation, but then be surprised by > > x[0] + 1 > -> 256 > > y[0] = 1 > x[0] + y[0] > -> 0 # WTH I'll go even further: I would say a common situation where people use syntax

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

On Tue, 22 Feb 2022, at 1:01 AM, Stefan van der Walt wrote: > it is easier to explain away `x + 1` behaving oddly over `x[0] + 1` behaving > oddly Is it? I find the two equivalent, honestly. > given that we pretend like NumPy scalars do not exist. This is the leaky abstraction that I think

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

On Mon, 21 Feb 2022, at 11:50 PM, Stefan van der Walt wrote: > Just to play a bit of devil's advocate here, I'd have to say that most people > will not expect > > x[0] + 200 > > To often yield a number less than 200! It's tricky though, because I would expect np.uint8(255) + 1 to be equal to

[Numpy-discussion] Re: NEP draft for the future behaviour of scalar promotion

> the > latter would seem consistent with the "principle of least surprise" when > moving from a typed language to > NumPy work perhaps, though arguably slightly less user-friendly if naively > doing some operations with > a less formal view of typing (new Python user messing around with NumPy?)

[Numpy-discussion] Re: An article on numpy data types

I'm surprised no one has mentioned it already: int and uint are reversed in the first table. I do agree with others that this is a great overview page that should be included in the numpy docs. Thanks Lev! Juan. On Sun, 26 Dec 2021, at 12:59 PM, Lev Maximov wrote: > I've tried to take into

[Numpy-discussion] Re: Allow for callable in indexing

I have to say I like this! Together with partial functions / toolz currying [1] it could make for some rather elegant code: result = gaussian_filter(image)[greater_than(t)] Juan. ..[1]: https://toolz.readthedocs.io/en/latest/curry.html On Wed, 24 Nov 2021, at 9:37 AM,

[Numpy-discussion] Re: Code formatters

> On 15 Nov 2021, at 8:23 am, Stefan van der Walt wrote: > > On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote: >> The black formatter is much improved in its latest version and I think good >> enough to start using. The main drawbacks that I see are: >> all operators, including '*' and

[Numpy-discussion] Re: Revert the return of a single NaN for `np.unique` with floating point numbers?

I agree with the argument to revert. Consistency among libraries should be near the top of the list of priorities, as should performance. Whether the new behaviour "makes more sense", meanwhile, is debatable. On Fri, 5 Nov 2021, at 4:08 PM, Ralf Gommers wrote: > > > On Mon, Aug 2, 2021 at

[Numpy-discussion] Re: spam on the mailing lists

The upside of discourse, though, is that those messages can be permanently deleted by moderators. In contrast, the mailing list archives appear unalterable... At any rate, those two messages (assuming we're talking about the same ones) don't appear to be spam, but rather a misunderstanding of

[Numpy-discussion] Re: spam on the mailing lists

On scikit-image, we've moderated *subscriptions*, and only subscribers can post without being moderated, but still spam gets through, because it's hard to vet whether an email address is "genuine", so sometimes we allow the subscription, and immediately receive resulting spam. A "reputation"

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

Personally I was a fan of the Enum approach. People dislike it because it is not “Pythonic”, but imho that is an accident of history because Enums only appeared (iirc) in Python 3.4. In fact, they are the right data structure for this particular problem, so for my money we should *make it*

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

gt; Tensor typing meeting details > <https://docs.google.com/document/d/1oaG0V2ZE5BRDjd9N-Tr1N0IKGwZQcraIlZ0N8ayqVg8/edit> > Thanks again, everyone! > > On Wed, 9 Jun 2021 at 22:28, Sebastian Berg <mailto:sebast...@sipsolutions.net>> wrote: > On Tue, 2021-06-08 at 11:40 -0700, Ste

Re: [Numpy-discussion] Tensor Typing presentation and discussion on Wednesday! (As part of the NumPy Community Meeting)

Hello! Any chance this could be recorded for those of us in useless time zones?  On Mon, 7 Jun 2021, at 6:03 PM, Sebastian Berg wrote: > Hi all, > > There will be a NumPy Community meeting Wednesday June 9th at > 20:00 UTC. > > This meeting will be dedicated to a presentation by Matthew and

Re: [Numpy-discussion] Looking for a difference between Numpy 0.19.5 and 0.20 explaining a perf regression with Pythran

Hi Pierre, If you’re able to compile NumPy locally and you have reliable benchmarks, you can write a script that tests the runtime of your benchmark and reports it as a test pass/fail. You can then use “git bisect run” to automatically find the commit that caused the issue. That will help

Re: [Numpy-discussion] NumPy logo merchandise

Yeah I desperately want those mitts! > On 5 Mar 2021, at 11:54 am, Stephan Hoyer

Re: [Numpy-discussion] ENH: Proposal to add atleast_nd function

; > I would love to see examples of this -- perhaps in matplotlib? > > My thinking is that in most cases it's probably a better idea to keep the > interface simpler, and raise an error for lower-dimensional arrays. Automatic > conversion is convenient (and endemic within

Re: [Numpy-discussion] ENH: Proposal to add atleast_nd function

I totally agree with the namespace clutter concern, but honestly, I would use `atleast_nd` with its `pos` argument (I might rename it to `position`, `axis`, or `axis_position`) any day over `at_least{1,2,3}d`, for which I had no idea where the new axes would end up. So, I’m in favour of

Re: [Numpy-discussion] np.{bool,float,int} deprecation

> On 13 Dec 2020, at 6:25 am, Sebastian Berg wrote: > > But "default" in NumPy really doesn't mean a whole lot? I can think of > three places where "defaults" exists: Huh? There are platform-specific defaults for literally every array creation function in NumPy? In [1]: np.array([4,

Re: [Numpy-discussion] np.{bool,float,int} deprecation

> I agree. I think we should recommend sane, descriptive names that do the > right thing. So ideally we'd have people spell their dtype specifiers as > dtype=bool # or np.bool > dtype=np.float64 > dtype=np.int64 > dtype=np.complex128 > The names with underscores at the end make little

[Numpy-discussion] np.{bool,float,int} deprecation

Hi all, At the prodding [1] of Sebastian, I’m starting a discussion on the decision to deprecate np.{bool,float,int}. This deprecation broke our prerelease testing in scikit-image (which, hooray for rcs!), and resulted in a large amount of code churn to fix [2]. To be honest, I do think

Re: [Numpy-discussion] NumPy 1.20.x branch in two weeks

I like Ralf's email, and most of all I agree that the existing wording is clearer. My view on the NEP is that it does not mandate dropping support, but encourage it. In my projects I would drop it if I had use for Python 3.7+ features. It so happens that we want to use PEP-593 so we were

[Numpy-discussion] Sprint leaders wanted for SciPy Japan

Hi NumPythonistas, and apologies cross-posting. I am sprints chair for the upcoming SciPy Japan virtual conference [1]. It’s running Oct 30-31 (main conference) and Nov 1-2 (sprints). This is the second SciPy Japan conference and the first with sprints. The sprints officially run from 9am to

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

y/blob/master/doc/neps/nep-template.rst > <https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst> > [7] > https://github.com/numpy/numpy/blob/master/doc/neps/nep-0038-SIMD-optimizations.rst > > <https://github.com/numpy/numpy/blob/master/doc/neps/nep-0038-SIMD-

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

I’ve generally been on the “let the NumPy devs worry about it” side of things, but I do agree with Ilhan that `like=` is confusing and `typeof=` would be a much more appropriate name for that parameter. I do think library writers are NumPy users and so I wouldn’t really make that distinction,

Re: [Numpy-discussion] Python for Climate Action session at SciPy'20

be happy to set up one on the topic of Python for Climate Action. > We could host it on July 8th or 10th at 5 - 6 p.m. CDT. Would you be > available to moderate it? > > > -- Forwarded message -- > From: Juan Nunez-Iglesias mailto:j...@fastmail.com>&g

Re: [Numpy-discussion] Proposal to add clause to license prohibiting use by oil and gas extraction companies

Hi everyone, If you live in Australia, this has been a rough year to think about climate change. After the hottest and driest year on record, over 20% of the forest surface area of the south east was burned in the bushfires. Although I was hundreds of kilometres from the nearest fire, the air

Re: [Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface

Hi everyone, and thank you Ralf for carrying the flag in my absence. =D Sebastian, the *primary* motivation behind avoiding detach() in PyTorch is listed in original post of the PyTorch issue: > People not very familiar with `requires_grad` and cpu/gpu Tensors might go > back and forth with

Re: [Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface

Hi everyone, > One bit of expressivity we would miss is “copy if necessary, but otherwise > don’t bother”, but there are workarounds to this. After a side discussion with Stéfan van der Walt, we came up with `allow_copy=True`, which would express to the downstream library that we don’t mind

[Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface

Hello NumPy-ers! The __array__ method is a great little tool to allow interoperability with NumPy. Briefly, calling `np.array()` or `np.asarray()` on an object with an `__array__` method, one can get a NumPy representation of that object, which may or may not involve data copying (this is up

Re: [Numpy-discussion] Put type annotations in NumPy proper?

I'd like to offer a +1 from skimage's perspective (and napari's!) for having NumPy types directly in the repo. We have been wanting to start using type annotations, but the lack of types in NumPy proper, together with the uncertainty about whether numpy-stubs was "officially supported" and

Re: [Numpy-discussion] New DTypes: Are scalars a central concept in NumPy or not?

I personally have always found it weird and annoying to deal with 0-D arrays, so +1 for scalars!* Juan *: admittedly, I have almost no grasp of the underlying NumPy implementation complexities, but I will happily take Sebastian's word that scalars can be consistent with the library. On Fri,

Re: [Numpy-discussion] "Proposal to accept NEP 34: Disallow inferring dtype=object from sequence

For what it’s worth, I support this NEP. I have indeed seen this mistake often when teaching NumPy. > On 17 Nov 2019, at 8:43 am, Matti Picus wrote: > > I propose to move the NEP https://numpy.org/neps/nep-0034.html from "draft" > to "accepted" status. There were no objections (actually

Re: [Numpy-discussion] Recommended way to utilize GPUs via OpenCL, ROCm

I have also used PyOpenCL quite profitably: https://github.com/inducer/pyopencl I philosophically prefer it to ROCm because it targets *all* GPUs, including intel integrated graphics on most laptops, which can actually get quite decent (30x) speedups. >

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

Hi all, and thank you for all your hard work with this. I wanted to provide more of an "end user" perspective than I think has been present in this discussion so far. Over the past month, I've quickly skimmed some emails on this thread and skipped others altogether. I am far from a NumPy

Re: [Numpy-discussion] Accepting NEP 29 — Recommend Python and Numpy version support as a community policy standard

We're behind this at scikit-image! Thank you to all who worked on this proposal! Minor typo: "at minimum the last THREE minor versions" Juan. On Thu, 3 Oct 2019, at 4:54 PM, Sebastian Berg wrote: > Hi all, > > we propose formally accepting the NumPy enhancement proposal 29: > > "Recommend

Re: [Numpy-discussion] did anyone create numpy.slack.com?

FWIW we use Zulip for scikit-image and we are very happy with it. See https://skimage.zulipchat.com . Advantages over Slack: - free for FOSS, including unlimited archives (https://zulipchat.com/for/open-source/ ) - login

Re: [Numpy-discussion] converting 1 dimensional array to 2 dimensional array

Hi Omry! You're looking for `.view()`: In [1]: import numpy as np In [2]: b = np.arange(1, 13).astype(np.uint8) In [4]: y = b.view(np.uint16).reshape((3, 2)) In [5]: y Out[5]: array([[ 513, 1027], [1541, 2055], [2569, 3083]], dtype=uint16) You can also change the endianness by replacing

Re: [Numpy-discussion] __array_function related regression for 1.17.0rc1

On Tue, 2 Jul 2019, at 4:34 PM, Stephan Hoyer wrote: > This is addressed in the NEP, see bullet 1 under "Partial implementation of > NumPy's API": > http://www.numpy.org/neps/nep-0018-array-function-protocol.html#partial-implementation-of-numpy-s-api > > My concern is that fallback coercion

Re: [Numpy-discussion] NumPy 1.17.0rc1 released

Hi Chuck, and thanks for putting this together! It seems the release has broken existing uses of dask array with `np.min` (I presume among other functions): https://github.com/dask/dask/issues/5031 Perhaps `__array_function__` should be switched off for one more release cycle? I imagine that

Re: [Numpy-discussion] Syntax Improvement for Array Transpose

On Mon, 24 Jun 2019, at 11:25 PM, Marten van Kerkwijk wrote: > Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape of > `(n, 1)` the right behaviour? I.e., it should still change from what it is > now - which is to leave the shape at `(n,)`. Just to chime in as a user: v.T

Re: [Numpy-discussion] Was the range() function ever created?

On Sat, 25 May 2019, at 1:49 PM, C W wrote: > I can't be the first person who asked about range() that calculates the > *actual* range of two numbers. Based on your mention of matlab's `range`, I think you're looking for numpy.ptp.

Re: [Numpy-discussion] Keep __array_function__ unexposed by default for 1.17?

I just want to express my general support for Marten's concerns. As an "interested observer", I've been meaning to give `__array_function__` a try but haven't had the chance yet. So from my anecdotal experience I expect that more people need to play with this before setting the API in stone.

Re: [Numpy-discussion] [SciPy-User] Why slicing Pandas column and then subtract gives NaN?

> I don’t have index when I read in the data. I just want to slice two series > to the same length, and subtract. That’s it! > > I also don’t what numpy methods wrapped within methods. They work, but hard > do understand. > > How would you do it? In Matlab or R, it’s very simple, one line.

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

> On 10 Jan 2019, at 6:35 pm, Todd wrote: > > Could this approach be used to deprecate `ravel` and let us just use > `flatten`? Could we not? `.ravel()` is everywhere and it matches `ravel_multi_index` and `unravel_index`.___ NumPy-Discussion

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Fri, Dec 28, 2018, at 10:58 AM, Ralf Gommers wrote: > > Technically there's nothing we are deprecating. If anything, the one not > super uncommon pattern will be that people use 0/1 instead of False/True, > which works as expected now and will start raising in case we'd go with >

Re: [Numpy-discussion] Add guaranteed no-copy to array creation and reshape?

On Fri, Dec 28, 2018, at 3:40 AM, Sebastian Berg wrote: > > It’s consistent with np.newaxis in spelling (modulo the _) > > If mistyped, it can be caught easily by IDEs. > > It’s typeable with mypy, unlike constant string literals which > > currently aren’t > > If code written against new numpy is

Re: [Numpy-discussion] Warn or immidiately change readonly flag on broadcast_arrays return value?

Probably this will cause a lot of groans, but I've definitely written code modifying `broadcast_to` outputs, intentionally. As such I am -1 on this whole endeavour. My preference on making arrays read-only is to have a very light touch if any. As an example, at some point `np.diag` started

Re: [Numpy-discussion] Adding "maximum difference" to np.testing.assert_array_equal errors

Another +1 on printing rtol, and +100 (can I do that?) on the overall idea! Thanks Stephan! On Thu, Dec 20, 2018, at 7:27 AM, Christoph Deil wrote: > > > > On 19. Dec 2018, at 19:50, Stefan van der Walt wrote: > > > > On Wed, 19 Dec 2018 09:47:01 -0800, Stephan Hoyer wrote: > >> Example

Re: [Numpy-discussion] PR Cleanup

> On 26 Sep 2018, at 5:12 am, Ralf Gommers wrote: > My $2c: I've had this "bot experience" happen to me once (for a pip > contribution), and that left a *really* bad taste. I’m going to second Ralf’s comments here. These bots are a great idea if your number one goal is to reduce the number of

Re: [Numpy-discussion] count_nonzero axis argument?

On Mon, Sep 17, 2018, at 9:37 PM, Matthew Brett wrote: > >>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1) > array([2, 1]) > > It would be much more useful if it did... You might know about this already, but I not too long ago discovered np.apply_along_axis [1], which is a magical

Re: [Numpy-discussion] pytest, fixture and parametrize

> I find the way that pytest automatically match *argument names* with > the names of fixtures very distasteful and un-Pythonic. THIS! I've been wanting to articulate this for a while but couldn't quite put my finger on it. Nevertheless, I agree with the sentiment in this thread, specifically

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

Let me start by thanking Robert for articulating my viewpoints far better than I could have done myself. I want to explicitly flag the following statements for endorsement: > *I would still reserve warnings and deprecation for the cases where > the current behavior gives us something that no one

Re: [Numpy-discussion] NEP 21: Simplified and explicit advanced indexing

> Plain indexing arr[...] should return an error for ambiguous cases. > [...] This includes every use of vectorized indexing with multiple > integer arrays. This line concerns me. In scikit-image, we often do: rr, cc = coords.T # coords is an (n, 2) array of integer coordinates values =

Re: [Numpy-discussion] Python 3 compatible examples

On Sat, Jun 2, 2018, at 6:22 AM, Pauli Virtanen wrote: > For Scipy, we converted the examples in the documentation to Python 3, > and have essentially ignored Python 2 compatibility. So far, I remember > no complaints about it. I vote for what Pauli said.

Re: [Numpy-discussion] Applying logical operations along an axis of a boolean array?

Use “np.all” or “np.any”. On 18 Dec 2017, 10:02 PM +1100, hanno_li...@gmx.net, wrote: > Hi, > > is it possible, to apply a logical operation, such as AND or OR along a > particular axis of a numpy array? > > Let's say I have an (n,m) array and I want to AND along the first axis, such > that I

Re: [Numpy-discussion] How to subset a matrix according to some criterion?

selector = target != 2 data, target = data[selector], target[selector] On 4 Dec 2017, 8:38 AM +1100, Peng Yu , wrote: > Hi, I'd like to select the rows of 'data' for which the corresponding > elements in 'target' is not 2. Could anybody let know what is the best > way (with

Re: [Numpy-discussion] Type annotations for NumPy

On 26 Nov 2017, 12:27 PM +1100, Nathaniel Smith , wrote: > It turns out that the PEP 484 type system is *mostly* not useful for > this. They're really designed for checking consistency across a large > code-base, not for enabling compiler speedups. For example, if you > annotate

Re: [Numpy-discussion] Type annotations for NumPy

This is a complete outsider’s perspective but (a) it would be good if NumPy type annotations could include an “array_like” type that allows lists, tuples, etc. (b) I’ve always thought (since PEP561) that it would be cool for type annotations to replace compiler type annotations for e.g. Cython

Re: [Numpy-discussion] Only integer scalar arrays can be converted to a scalar index

@Robert, good point, always good to try out code before speculating on a thread. ;) Here’s working code to do the averaging, though it’s not block-wise, you’ll have to add that on top with dask/util.apply_parallel. Note also that because of the C-order of numpy arrays, it’s much more efficient

Re: [Numpy-discussion] Only integer scalar arrays can be converted to a scalar index

+1 on the astype(int) call. +1 also on using dask. scikit-image has a couple of functions that might be useful: - skimage.util.apply_parallel: applies a function to an input array in chunks, with user-selectable chunk size and margins. This is powered by dask. - skimage.util.view_as_windows:

Re: [Numpy-discussion] Vector stacks

I’m with Nathaniel on this one. Subclasses make code harder to read and reason about because you now have to be sure of the exact type of things that users are passing you — which are array-like but subtly different. On 2 Jul 2017, 9:46 AM +1000, Marten van Kerkwijk ,

Re: [Numpy-discussion] proposed changes to array printing in 1.14

I agree that shipping a sane/sanitising doctest runner would go 95% of the way to alleviating my concerns. Regarding 2.0, this is the whole point of semantic versioning: downstream packages can pin their dependency as 1.x and know that they - will continue to work with any updates - won’t make

Re: [Numpy-discussion] proposed changes to array printing in 1.14

To reiterate my point on a previous thread, I don't think this should happen until NumPy 2.0. This *will* break a massive number of doctests, and what's worse, it will do so in a way that makes it difficult to support doctesting for both 1.13 and 1.14. I don't see a big enough benefit to these