Re: [Numpy-discussion] (no subject)

[Derek Homeier]

On 2 Jun 2020, at 11:15 pm, Charles R Harris  wrote:
> 
>> Also, I had expected the sdist to be the .tar.gz format, I can't find it 
>> back but IIRC that's what we decided in the past. It's smaller, and it's 
>> what pretty much all other projects do.
> 
> NumPy has always used zip since PyPI limited the number of source releases. 
> We did that before SciPy.
> 
The .tar.gz version (if file size really is an issue, why not using .tar.xz?) 
is also available from
https://github.com/numpy/numpy/releases
and already was before the PyPI upload was completed.

Cheers,
Derek

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

[Numpy-discussion] NumPy 1.18.5 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team I am pleased to announce the release of NumPy
1.18.5. This is a short release to enable pickle protocol=5 to be used in
Python3.5 and is motivated by the recent backport of pickle5 to Python3.5.

The Python versions supported in this release are 3.5-3.8. Downstream
developers should use Cython >= 0.29.15 for Python 3.8 support and OpenBLAS
>= 3.7 to avoid errors on the Skylake architecture. Wheels for this release
can be downloaded from PyPI , source
archives and release notes are available from Github
.

*Contributors*

A total of 3 people contributed to this release. People with a \"+\" by
their names contributed a patch for the first time.

   - Charles Harris
   - Matti Picus
   - Siyuan Zhuang +


*Pull requests merged*

A total of 2 pull requests were merged for this release.

   - #16439: ENH: enable pickle protocol 5 support for python3.5
   - #16441: BUG: relpath fails for different drives on windows


Cheers,

Charles Harris
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] (no subject)

[Charles R Harris]

On Wed, Jun 3, 2020 at 12:34 PM Derek Homeier <
de...@astro.physik.uni-goettingen.de> wrote:

> On 2 Jun 2020, at 11:15 pm, Charles R Harris 
> wrote:
> >
> >> Also, I had expected the sdist to be the .tar.gz format, I can't find
> it back but IIRC that's what we decided in the past. It's smaller, and it's
> what pretty much all other projects do.
> >
> > NumPy has always used zip since PyPI limited the number of source
> releases. We did that before SciPy.
> >
> The .tar.gz version (if file size really is an issue, why not using
> .tar.xz?) is also available from
> https://github.com/numpy/numpy/releases
> and already was before the PyPI upload was completed.
>

The archive files automatically generated by Github are faulty and cannot
be used, you need to use the ones uploaded later. I choose zip because it
is universally available and since we can only put one source release on
PyPI, that was my choice. Before PyPI adopted the single source policy we
would upload both.

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

[Numpy-discussion] Fixing fromfile to throw error when opening on gzip files

[Sidhant Bansal]

In regard to the issue: https://github.com/numpy/numpy/issues/7713
And my corresponding PR: https://github.com/numpy/numpy/pull/16221

I was advised to put this on the mailing list to get a general sense of how
the issue is affecting people and to discuss how I can improve the current
PR.

I am still interested in resolving this issue, so will be glad to do some
re-work to be able to get this merged and fix the issue.

The currently proposed PR is a kind of band-aid solution which uses an
if-else chunk in the `fromfile` function's internal implementation to catch
if the file opened is gzip type or not and throws an error.

The drawback lies in the fact that we only are able to resolve gzip type
issue and is not extendable to other high level file types which cant be
opened.

In my findings, I was unable to find a common distinguishing feature for
those file types which cannot be opened using fromfile vs those which can
be (ex. In a hypothetical situation one kind has the read method and other
doesn't).

Would love to hear what other people think and if they have any inputs
about the what possible common distinguishing features can be there or if
we should simply cross-check the file type against a hard-coded list of
common high-level file types?

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