You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trying to narrow differences... since mmap is coming from the standard lib I suspected a change in Python versions and how repr(mmap_obj) or str(mmap_obj) is displayed... Its possible, though still smells to me so needs a sanity check.
As evidence, though, comparing against a prior (chose #1096 as the most recent unmerged green build I saw....)
Looking at numpy/numpy@f996a2b...0eaa40d, I see they merged numpy/numpy#21324 in that interval, which seems likely to be the cause. It does not look like it actually performs a copy, so that's probably okay. It looks like the reason the test was written this way:
NetCDF files, when opened read-only, return arrays that refer
directly to memory-mapped data on disk:
>>> data = time[:]
>>> data.base.base # doctest: +ELLIPSIS
<mmap.mmap ...>
is because the object is not actually a numpy.memmap but a custom mmap.mmap-backed ndarray.
It looks like scipy didn't hit this because they dropped this test (although not the surrounding text) in scipy/scipy@6d40ad4 as part of scipy/scipy#14832.
Not quite sure where that leaves us. The easy thing is to follow Scipy's lead and drop the test, though I'd then go ahead and drop the text that indicates that mmap should appear. I don't know if the better solution would be to find an alternative test to ensure that the mmap functionality isn't damaged by future releases, and ensure it gets upstreamed into scipy.
most recent failing job as of this writing May 7
Trying to narrow differences... since
mmap
is coming from the standard lib I suspected a change in Python versions and howrepr(mmap_obj)
orstr(mmap_obj)
is displayed... Its possible, though still smells to me so needs a sanity check.As evidence, though, comparing against a prior (chose #1096 as the most recent unmerged green build I saw....)
Python version comparison
Final note: the only pre-release job that passes is the one that does not have the PRE_PIP_FLAGS environment variable set....
Originally posted by @jacobdr in #1105 (comment)
The text was updated successfully, but these errors were encountered: