If functionality is available in SciPy we usually don’t consider adding it
to NumPy. That rules out adding eig.
Is there any reason why polyeig doesn’t make sense to add to SciPy instead
of NumPy? Generally if functionality makes sense to add to SciPy that’s
where we point people to.
On Thu, Jun
NumPy probably isn’t the right spot for this - we’re very conservative
about adding new functionality to NumPy that might also live in SciPy.
SciPy has convolution functionality but I’m not sure if they would want
greenfield code for this. Definitely worth asking the SciPy developers.
That said, h
hings to use the
new system, as well as the bot that auto-applies labels. You could probably
use a script rather than doing it manually.
-Nathan
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discuss
Improvements to the promoters for some of the string ufuncs:
https://github.com/numpy/numpy/pull/27636
Support for stringdtype arrays in the type hints and typing support for the
string ufuncs:
https://github.com/numpy/numpy/pull/27470
If you have a particular improvement you’re looking for I’d l
inclined to do anything
about it at all.
In that case, I think moving things to an external pypi package along with
a long-lived shim in NumPy that points people to the pypi package is
probably the least disruptive thing to do, if we're going to do anything.
-Nathan
__
Thanks for clarifying! In that case I think endorsing SPEC 7 makes sense.
On Tue, Oct 8, 2024 at 3:08 PM Robert Kern wrote:
> On Tue, Oct 8, 2024 at 8:36 AM Nathan via NumPy-Discussion <
> numpy-discussion@python.org> wrote:
>
>>
>> Since the legacy RNG interface
Regarding thread safety - that's not a problem. At least for Python 3.13,
the GIL is temporarily re-enabled during imports. That won't necessarily be
true in the future, but separately CPython also uses per-module locks on
import, so there shouldn't be any issues with threads simultaneously
importi
That seems reasonable to me on its face. There are some corner cases to
work out though.
Swayam is tinkering with a quad precision dtype written using rhe new DType
API and just ran into the fact that finfo doesn’t support user dtypes:
https://github.com/numpy/numpy/issues/27231
IMO any new feat
Why are you rebasing after fetching? You provably don’t want to rebase
what’s supposed to be a public branch on top of a public commit like that.
To make sure your fork and upstream numpy have the same main branch, do:
git fetch numpy main
git checkout numpy/main
git branch -f main
git checkout m
On Wed, Jul 17, 2024 at 1:26 PM Stefan van der Walt
wrote:
> Hi Nathan,
>
> On Tue, Jul 16, 2024, at 12:24, Nathan wrote:
>
> I just pushed some commits to the numpy-user-dtypes repo (
> https://github.com/numpy/numpy-user-dtypes) that fixes compatibility with
> the public
you’re curious about any of that please subscribe to the repo and open
issues or respond here.
Nathan
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org
numpy C API. We cleaned that up, but that means C extensions
now need to do this import dance correctly.
Hope that helps,
Nathan
On Fri, May 24, 2024 at 12:52 PM Pavlyk, Oleksandr <
oleksandr.pav...@intel.com> wrote:
> I am working to transition mkl_fft and mkl_random to NumPy 2.0.
call using private APIs like
_multiarray_umath.
Obviously writing CPython C API code is a lot less straightforward than
Python, but the numpy code reviewers have a lot of experience spotting C
API issues and we can point you to resources for learning.
Hope that helps,
Nathan
On Sat, May 11, 2024
I think you're looking for the errstate context manager:
https://numpy.org/doc/stable/reference/generated/numpy.errstate.html
On Thu, May 9, 2024 at 1:11 PM wrote:
> The current way (according to 1.26 doc) of setting and resetting error is
> ```
> old_settings = np.seterr(all='ignore') #seterr
I think most of the build failures you’re seeing would be fixed by merging
with or rebasing on the latest main branch.
Note that there is currently an issue with some of the windows CI runners,
so you’ll see failures related to our spin configuration failing to handle
a gcov argument that was adde
That time work for me, I have a conflict with the old time an hour earlier
than the current time so hopefully that works for everyone.
On Sun, Apr 7, 2024 at 8:34 PM Matti Picus wrote:
> Could we move the weekly community/triage meetings one hour later? Some
> participants have a permanent confl
On Fri, Mar 29, 2024 at 8:39 AM Jim Pivarski wrote:
> On Fri, Mar 29, 2024 at 8:07 AM Steven G. Johnson wrote:
>
>> Should a dtype=object array be treated more like Python lists for type
>> detection/coercion reasons? Currently, they are treated quite differently:
>> >>> np.isfinite([1,2,3])
>
that all elements of an array are still of the
> same size in memory?
>
> I am thinking along the lines of per-element dynamic memory management.
> Such that if I had array [0, 1e1], the first element would default to
> reasonably small size in memory.
>
> On 13 Mar 2024, at 16
It is possible to do this using the new DType system.
Sebastian wrote a sketch for a DType backed by the GNU multiprecision float
library:
https://github.com/numpy/numpy-user-dtypes/tree/main/mpfdtype
It adds a significant amount of complexity to store data outside the array
buffer and introduces
keywords in
the API and now that the array API is a thing, we can point to that as a
place to hash out API decisions.
Including syntax in the array API also encourages more libraries to adopt
your preferred syntax.
Nathan
On Thu, Feb 29, 2024 at 4:12 PM wrote:
> Hoping to get some more feedback
On Mon, Feb 19, 2024 at 3:20 PM Amogh Sood wrote:
> Hi all.
>
> I want to thank you all for your contributions and efforts in maintaining
> numpy.
> numpy has been an indispensable tool during both my graduate and
> undergraduate studies.
>
> While I am no software wizard, going forward, I do wan
effort, Matti Picus, Stéfan
van der Walt, Ben Nathanson, Marten van Kerkwijk, who co-authored the NEPs,
Ralf Gommers who helped get funding for my work and provided mentoring and
coordination, Charles Harris for providing leadership, context, and advice,
and many others who hav
array entry without adding
complexity or needing to re-allocate the entire arena buffer.
For example, if you create an array with a short string entry and then edit
that entry to be longer than 15 bytes. Rather than appending to the arena
or re-allocating it, we convert the entry to a heap string.
Hi all,
I propose we accept NEP 55 and merge PR #25347 implementing the NEP in time
for the NumPy 2.0 RC:
https://numpy.org/neps/nep-0055-string_dtype.html
https://github.com/numpy/numpy/pull/25347
The most controversial aspect of the NEP was support for missing strings
via a user-supplied senti
pe code
please reply here, on github, or reach out to me privately.
On Wed, Nov 22, 2023 at 1:22 PM Nathan wrote:
> Hi all,
>
> This week I updated NEP 55 to reflect the changes I made to the prototype
> since
> I initially sent out the NEP. The updated NEP is available on the NumPy
efan van der Walt
wrote:
> On Sun, Nov 26, 2023, at 12:03, Nathan wrote:
>
> For my work I tend to use a persistent build directory with build
> isolation disabled as discussed in the meson-python docs.
>
>
> Out of curiosity, how is this different from, e.g., `
I want to caution about using `pip install -e .` to get a development
install of numpy. This will work fine working on numpy itself, but won’t be
useful if you need to use the development version of numpy to build another
library. This doesn’t work because in-place installs don’t install the
numpy
as:stringdtype
Thanks all for your time, attention, and help reviewing the NEP!
-Nathan
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/num
e and use attribute access or use `from` imports, which both invoke
the module-level `__getattr__`. Hopefully we’ll get most of the benefit of
alerting users that they are using private internals without needing to
break old pickles.
>
>
> On Tue, Oct 10, 2023 at 3:33 PM Nathan
On Tue, Oct 10, 2023 at 7:03 AM Ronald van Elburg <
r.a.j.van.elb...@hetnet.nl> wrote:
> I have one more useCase to consider from our ecosystem.
>
> We dump numpy arrays into a MongoDB using GridFS for subsequent
> visualization, some snippets:
>
> '''Python
> with BytesIO() as BIO:
>
On Mon, Oct 9, 2023 at 3:58 PM Oscar Benjamin
wrote:
> On Mon, 9 Oct 2023 at 22:30, Nathan wrote:
> >
> > On Mon, Oct 9, 2023 at 3:12 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>
> >> On Mon, 9 Oct 2023 at 21:57, Nathan wrote:
> >
On Mon, Oct 9, 2023 at 3:12 PM Oscar Benjamin
wrote:
> On Mon, 9 Oct 2023 at 21:57, Nathan wrote:
> >
> > On Mon, Oct 9, 2023 at 2:44 PM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >> Suppose that there is NumPy v1 and that in future there will be
On Mon, Oct 9, 2023 at 2:44 PM Oscar Benjamin
wrote:
> On Mon, 9 Oct 2023 at 17:03, Nathan wrote:
> >
> > On Mon, Oct 9, 2023 at 12:57 AM Aaron Meurer wrote:
> >>
> >> Is it possible to convert a NumPy 1 pickle file into a generic pickle
> >> file tha
ion that
will allow people to continue loading old pickle files indefinitely (albeit
with a minor code change). This also gives us a place to put compatibility
fixes for future changes that impact old pickle files.
-Nathan
>
> Aaron Meurer
>
> On Fri, Oct 6, 2023 at 10:17 AM Nathan wro
I don’t think this will be a problem for using pickle for IPC.
For the python multiprocessing module, all processes would be running the
same numpy version, so there wouldn’t be a problem.
It could be an issue if pickle is used to communicate numpy arrays between
a subset of workers running numpy
ithub.com/numpy/numpy/issues/24844, and the discussion in
https://github.com/numpy/numpy/pull/24634 for more context.
-Nathan
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@p
gt;
>>>
>>> On Fri, Sep 15, 2023 at 3:18 PM Warren Weckesser <
>>> warren.weckes...@gmail.com> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Sep 11, 2023 at 12:25 PM Nathan
>>> wrote:
>>> >>
>>> >
On Wed, Sep 20, 2023 at 12:26 AM Warren Weckesser <
warren.weckes...@gmail.com> wrote:
>
>
> On Fri, Sep 15, 2023 at 3:18 PM Warren Weckesser <
> warren.weckes...@gmail.com> wrote:
> >
> >
> >
> > On Mon, Sep 11, 2023 at 12:25 PM Nathan
> w
Looking at a py-spy profile of a slightly modified version of the code you
shared, it seems the difference comes down to NumPy's sorting
implementation simply being faster for ints than unicode strings. In
particular, it looks like string_quicksort_ is two
or three times slower than quicksort_ when
On Sun, Sep 3, 2023 at 10:54 AM Warren Weckesser
wrote:
>
>
> On Tue, Aug 29, 2023 at 10:09 AM Nathan wrote:
> >
> > The NEP was merged in draft form, see below.
> >
> > https://numpy.org/neps/nep-0055-string_dtype.html
> >
> > On Mon, Aug 21, 202
The NEP was merged in draft form, see below.
https://numpy.org/neps/nep-0055-string_dtype.html
On Mon, Aug 21, 2023 at 2:36 PM Nathan wrote:
> Hello all,
>
> I just opened a pull request to add NEP 55, see
> https://github.com/numpy/numpy/pull/24483.
>
> Per NEP 0, I've
Hello all,
I just opened a pull request to add NEP 55, see
https://github.com/numpy/numpy/pull/24483.
Per NEP 0, I've copied everything up to the "detailed description" section
below.
I'm looking forward to your feedback on thi
This has come up before, see https://github.com/numpy/numpy/issues/6044 for
the first time this came up; there were several subsequent discussions
linked there.
In the meantime, the data APIs consortium has been actively working on
adding a `cumulative_sum` function to the array API standard, see
Hi all,
As you may know, I'm currently working on a variable-width string dtype
using the new experimental user dtype API. As part of this work I'm running
into papercuts that future dtype authors will likely hit and I've been
trying to fix them as I go.
One issue I'd like to raise with the list
Thanks so much everyone!
On Mon, May 29, 2023 at 9:00 AM Ross Barnowski wrote:
> Welcome Nathan!
>
> On Mon, May 29, 2023 at 7:47 AM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Mon, May 29, 2023 at 1:15 AM Sebastian Berg <
>&
On Mon, Feb 13, 2023 at 4:34 AM Sebastian Berg
wrote:
> On Sat, 2023-02-11 at 11:24 +, Ralf Gommers wrote:
> > On Fri, Feb 10, 2023 at 5:35 PM Nathan
> > wrote:
> >
>
>
> > > >
> > >
> > > Small bikeshed: the name np.types indicates
On Fri, Feb 10, 2023 at 3:31 AM Sebastian Berg
wrote:
> Hi all,
>
> I was wondering if we should introduce a new `np.types` namespace. The
> main reason is that we have the DType classes, that most users don't
> need to worry about. These mirror the scalar classes, but getting them
> is weird c
the discussion in
https://github.com/numpy/numpy/issues/15544 for more context.
-Nathan
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists
Yeah, that seems to be more popular:
https://github.com/search?q=%22dtype%3Dnp.integer%22&type=Code
On Fri, Feb 14, 2020 at 2:45 PM Sebastian Berg
wrote:
> On Fri, 2020-02-14 at 14:39 -0700, Nathan wrote:
> > For what it's worth, github search only finds two instances
For what it's worth, github search only finds two instances of this usage:
https://github.com/search?q=%22np.dtype%28np.floating%29%22&type=Code
On Fri, Feb 14, 2020 at 2:28 PM Sebastian Berg
wrote:
> Hi all,
>
> In https://github.com/numpy/numpy/pull/15534 I would like to start
> deprecating c
On Sun, Sep 8, 2019 at 7:27 PM Nathaniel Smith wrote:
> On Sun, Sep 8, 2019 at 8:40 AM Ralf Gommers
> wrote:
> >
> >
> >
> > On Sun, Sep 8, 2019 at 12:54 AM Nathaniel Smith wrote:
> >>
> >> On Fri, Sep 6, 2019 at 11:53 AM Ralf Gommers
> wrote:
> >> > On Fri, Sep 6, 2019 at 12:53 AM Nathaniel S
It might be worth using BigQuery to search the github repository public
dataset for usages of np.sinc with keyword arguments.
On Wed, May 22, 2019 at 1:05 PM Sebastian Berg
wrote:
> Hi all,
>
> there is an open PR (https://github.com/numpy/numpy/pull/12924) to
> convert `np.sinc` into a ufunc. S
SciPy 2019, the 18th annual Scientific Computing with Python conference,
will be held July 8-14, 2019 in Austin, Texas. The annual SciPy Conference
brings together over 800 participants from industry, academia, and
government to showcase their latest projects, learn from skilled users and
developer
traffic
(perhaps 10% of the number of questions that get asked on StackOverflow)
and it’s a good venue for asking quick questions. Let’s hope that forcing
people to register doesn’t kill that, although there’s not much we can do
given the spam attack.
Nathan
On Mon, Aug 6, 2018 at 9:03 PM Matti Picus
On Wed, Aug 1, 2018 at 9:49 AM, Ralf Gommers wrote:
>
>
> On Wed, Aug 1, 2018 at 12:20 AM, Nathan Goldbaum
> wrote:
>
>> I realize this was probably brought up in the discussions about the scipy
>> code of conduct which I have not looked at, but I’m troubled by the
I realize this was probably brought up in the discussions about the scipy
code of conduct which I have not looked at, but I’m troubled by the
inclusion of “political beliefs” in the document.
See e.g.
https://github.com/jupyter/governance/pull/5
As a thought experiment, what if someone’s politica
Hi Chuck,
Is there a summary of the differences with respect to rc1 somewhere?
Nathan
On Mon, Jul 9, 2018 at 5:08 PM Charles R Harris
wrote:
> Hi All,
>
> On behalf of the NumPy team I'm pleased to announce the release of NumPy
> 1.15.0rc2.
> This release has an unusua
On Mon, Jul 2, 2018 at 7:42 PM Andrew Nelson wrote:
>
>
> On Tue, 3 Jul 2018 at 09:31, Charles R Harris
> wrote:
>
>>
>> ISTR that some parallel processing applications sent pickled arrays
>> around to different processes, I don't know if that is still the case, but
>> if so, no copy might be a
I think Matthew Brett needs to fix this.
On Mon, Jun 18, 2018 at 3:20 PM Charles R Harris
wrote:
> Hi All,
>
> I've been trying to put out the NumPy 1.15.0rc1, but cannot get
> `numpy-wheels` to upload the wheels to rackspace on windows, there is a
> certification problem. I note that that requi
OK I guess I missed that announcement.
I wouldn’t mind more than one email with a reminder to test.
On Wed, Jun 13, 2018 at 7:42 PM Charles R Harris
wrote:
> On Wed, Jun 13, 2018 at 6:28 PM, Nathan Goldbaum
> wrote:
>
>> Hi Chuck,
>>
>> Are you planning on doing
prerelease so numpy and other projects can implement workarounds as
needed without doing a release that might potentially break real users who
happen to install right after numpy 1.x.0 comes out.
Best,
Nathan Goldbaum
On Wed, Jun 13, 2018 at 7:11 PM Charles R Harris
wrote:
> Hi All,
>
> T
es for
the noise.
On Tue, Jun 5, 2018 at 7:39 PM, Nathan Goldbaum
wrote:
> Hmm, does this mean the callable that gets passed into __array_ufunc__
> will change? I'm pretty sure that will break the dispatch mechanism I'm
> using in my __array_ufunc__ implementation, which
Hmm, does this mean the callable that gets passed into __array_ufunc__ will
change? I'm pretty sure that will break the dispatch mechanism I'm using in
my __array_ufunc__ implementation, which directly checks whether the
callable is in one of several tuples of functions that have different
behavior
Perhaps I missed this but I didn’t see: what happens when both
__array_ufunc__ and __array_function__ are defined? I might want to do this
to for example add support for functions like concatenate or stack to a
class that already has an __array_ufunc__ defines.
On Sat, Jun 2, 2018 at 5:56 PM Steph
oes such a citation exist?
Thanks!
-Nathan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
I don't particularly need this, although it would be nice to make this
behavior explicit, instead of happening more or less by accident:
In [1]: from yt.units import km
In [2]: import numpy as np
In [3]: data = [1, 2, 3]*km
In [4]: np.ones_like(data)
Out[4]: YTArray([1., 1.,
On Thu, May 10, 2018 at 9:51 PM Stuart Reynolds
wrote:
> np.float(scalar)
>
This actually isn't right. It's a common misconception, but np.float is an
alias to the built-in float type. You probably want np.float_(scalar)
In [5]: np.float_(12).dtype
Out[5]: dtype('float64')
In [6]: np.float is
In [1]: import numpy as np
In [2]: np.float64(12)
Out[2]: 12.0
In [3]: np.float64(12).dtype
Out[3]: dtype('float64')
On Thu, May 10, 2018 at 9:49 PM Hameer Abbasi
wrote:
> Hello, everyone!
>
> I might be missing something and this might be a very stupid and redundant
> question, but is there a
ackage. At least that way others won't need to deal
with the pain :)
> - Joe
>
> On Thu, Apr 26, 2018 at 12:51 PM, Hameer Abbasi > wrote:
>
>> Hi Nathan,
>>
>> np.any and np.all call np.or.reduce and np.and.reduce respectively, and
>> unfortunately the u
On Thu, Apr 26, 2018 at 11:52 AM Hameer Abbasi
wrote:
> Hi Nathan,
>
> np.any and np.all call np.or.reduce and np.and.reduce respectively, and
> unfortunately the underlying function (ufunc.reduce) has no way of
> detecting that the value isn’t going to change anymore. It’s also
he of getting wheels built and conda-forge packages set up on all
platforms.
Thanks for your help!
-Nathan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
On Tue, Apr 10, 2018 at 9:59 AM, Stefan van der Walt
wrote:
> Hi Eric,
>
> On Sun, 08 Apr 2018 08:02:19 -1000, Eric Firing wrote:
> > On 2018/04/07 9:19 PM, Stefan van der Walt wrote:
> > > We would love community input on identifying the best areas & issues to
> > > pay attention to,
> >
> > Wha
numpy.float is an alias to the python float builtin.
https://github.com/numpy/numpy/issues/3998
On Thu, Mar 22, 2018 at 2:26 PM Olivier wrote:
> Hello,
>
>
> Is it normal, expected and desired that :
>
>
> round(numpy.float64(0.0)) is a numpy.float64
>
>
> while
>
> round(numpy.flo
On Thu, Nov 2, 2017 at 5:21 PM, Stephan Hoyer wrote:
> On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum
> wrote:
>
>> Would this issue be ameliorated given Nathaniel's proposal to try to move
>> away from subclasses and towards storing data in dtypes? Or would that just
On Thu, Nov 2, 2017 at 2:37 PM, Stephan Hoyer wrote:
> On Thu, Nov 2, 2017 at 9:45 AM wrote:
>
>> similar, scipy.special has ufuncs
>> what units are those?
>>
>> Most code that I know (i.e. scipy.stats and statsmodels) does not use only
>> "normal mathematical operations with ufuncs"
>> I guess
I think the biggest issues could be resolved if __array_concatenate__ were
finished. Unfortunately I don't feel like I can take that on right now.
See Ryan May's talk at scipy about using an ndarray subclass for units and
the issues he's run into:
https://www.youtube.com/watch?v=qCo9bkT9sow
On W
I’m using it in yt. If we were able to drop support for all old numpy
versions, switching would allow me to delete hundreds of lines of code.
As-is since we need to simultaneously support old and new versions, it adds
some additional complexity. If you’re ok with only supporting numpy >=
1.13, arra
encounters these days.
Please correct me if I'm wrong, Nathaniel.
-Nathan
On Thu, Oct 26, 2017 at 5:14 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Nathaniel,
>
> Thanks for the link. The plans sounds great! You'll not be surprised
> to hear I&
This is a change in the UI that github introduced a couple weeks ago during
their annual conference.
See https://github.com/blog/2447-a-more-connected-universe
On Wed, Oct 18, 2017 at 11:49 AM Charles R Harris
wrote:
> On Wed, Oct 18, 2017 at 7:23 AM, Sebastian Berg <
> sebast...@sipsolutions.n
The latest version of numpy is 1.13.
In this case, as described in the docs, a power function distribution is
one with a probability desnity function of the form ax^(a-1) for x between
0 and 1.
On Thu, Aug 24, 2017 at 9:41 AM, Renato Fabbri
wrote:
> Thanks for the reply.
>
> But the question re
See
https://mail.scipy.org/pipermail/numpy-discussion/2012-August/063589.html
and replies in that thread.
Quote from an Apple engineer in that thread:
"For API outside of POSIX, including GCD and technologies like Accelerate,
we do not support usage on both sides of a fork(). For this reason amon
Just as a comment: It would be really nice if NumPy could slow down the
pace of deprecations, or at least make the warnings about deprecations more
visible. It seems like every release breaks some subset of our test suite
(we only had one or two cases of using the binary - operator on boolean
array
I don't think there's any real standard here. Just doing a github search
reveals many different choices people have used:
https://github.com/search?l=Python&q=__array_priority__&type=Code&utf8=%E2%9C%93
On Mon, Jun 19, 2017 at 11:07 AM, Ilhan Polat wrote:
> Thank you. I didn't know that it exis
Hi Chuck,
Is there a docs build for this release somewhere? I'd like to find an
authoritative reference about __array_ufunc__, which I'd hesistated on
looking into until now for fear about the API changing.
Nathan
On Wed, May 10, 2017 at 8:49 PM Charles R Harris
wrote:
> Hi
Thanks for linking to the updated NEP, I've been looking for a good
overview of this discussion. Up until now I haven't wanted to wade through
the extensive discussion on this topic.
I'm curious, if I want to simultaneously support older Numpy versions as
well as newer versions, will I be able to
85 matches
Mail list logo
