Re: [Numpy-discussion] Dropping Python 3.7 for NumPy 1.22

[Ralf Gommers]

On Fri, Aug 13, 2021 at 3:41 AM Charles R Harris 
wrote:

> Hi All,
>
> This is to propose dropping Python 3.7 for NumPy 1.22. Doing so will allow
> merging the array API standard  
> (keyword
> only arguments), simplify removing import time compiles
> , allow making 64 bit pickles
> the default, and bring annotations closer to current. NEP 29
>  suggests Dec
> 26, 2021 for the drop date, which is close to the likely 1.22 release date,
> but given the advantages of dropping 3.7 I think there are good reasons to
> cheat by a week or two if needed. Downstream projects releasing after 1.22
> will probably want to drop Python 3.7 anyway, as they will be past the
> deadline.
>
> Thoughts?
>

+1 from me. Python 3.10 is out by then, and supporting three Python
releases for 1.22 seems fine. And the benefits are interesting.

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

[Numpy-discussion] Idea: Simplify passing of shared memory info for ndarrays

[Randall Pittman]

Hi! First time poster to the list, long time happy user of NumPy (thank you, 
devs!!)

I created a bit of a wrapper for using `ndarray` with Py 3.8+ 
`multiprocessing.shared_memory`. I really like the ability to use 
`SharedMemory` with `ndarray` via the `buffer` arg. (as in 
https://docs.python.org/3/library/multiprocessing.shared_memory.html#multiprocessing.shared_memory.SharedMemory)
 However, it seemed a bit clunky to worry about passing the SharedMemory object 
or name, dtype, and shape to reconstruct the `ndarray` in other processes. I 
came up with this SharedNDArray class that encapsulates that information and 
provides an ephemeral `ndarray` interface: 
https://gitlab.com/osu-nrsg/shared-ndarray2. It's especially meant for use in a 
`SharedMemoryManager` context manager.

I shared it on r/Python and someone suggested I share it here for your input 
(and maybe even integration into NumPy rather than the lone-wolf project it 
currently is).

I'm happy to receive any suggestions/input/criticism.

As an aside, I discovered that it's not at all trivial and, at the moment, not 
technically possible to define all the possible typing overloads of ndarray 
`__setitem__` and `__getitem__`. Stll, I enjoyed making use of 
np.typing.NDArray.

Thanks for your consideration,
Randy
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion