Re: [Numpy-discussion] deprecate fromstring() for text reading?

[Marten van Kerkwijk]

I think it would be good to keep the usage to read binary data at least. Or
is there a good alternative to `np.fromstring(, dtype=...)`?  --
Marten

On Thu, Oct 22, 2015 at 1:03 PM, Chris Barker  wrote:

> There was just a question about a bug/issue with scipy.fromstring (which
> is numpy.fromstring) when used to read integers from a text file.
>
> https://mail.scipy.org/pipermail/scipy-user/2015-October/036746.html
>
> fromstring() is bugging and inflexible for reading text files -- and it is
> a very, very ugly mess of code. I dug into it a while back, and gave up --
> just to much of a mess!
>
> So we really should completely re-implement it, or deprecate it. I doubt
> anyone is going to do a big refactor, so that means deprecating it.
>
> Also -- if we do want a fast read numbers from text files function (which
> would be nice, actually), it really should get a new name anyway.
>
> (and the hopefully coming new dtype system would make it easier to write
> cleanly)
>
> I'm not sure what deprecating something means, though -- have it raise a
> deprecation warning in the next version?
>
> -CHB
>
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] numpy-1.11.0.dev0 windows wheels compiled with mingwpy available

[Robert McGibbon]

Got it. Thanks, Nathaniel -- this is really good information.

-Robert

On Mon, Oct 19, 2015 at 6:55 PM, Nathaniel Smith  wrote:

> On Mon, Oct 19, 2015 at 2:26 AM, Olivier Grisel
>  wrote:
> >> Is it possible to test this with py35 as well?
> >
> > Unfortunately not yet.
> >
> >> For MSVC, py35 requires a new compiler toolchain (VS2015) -- is that
> >> something mingwpy/mingw-w64 can handle?
> >
> > I am pretty sure that mingwpy does not support Python 3.5 yet.
>
> Correct.
>
> > I don't know the status of the interop of mingw-w64 w.r.t. VS2015 but as
> far
> > as I know it's not supported yet either. Once the issue is fixed at the
> > upstream level, I think mingwpy could be rebuilt to benefit from the fix.
>
> Upstream mingw-w64 doesn't support interop with any version of visual
> studio that was released this millennium -- all the interop stuff is
> new in mingwpy.
>
> VS2015 had a major reorganization of how it handles runtime libraries,
> so it's not quite so trivial as just adding support the same way as
> was done for VS2008 and VS2010. Or rather, IIUC: we *could* just add
> support the same way as before, but there are undocumented rules about
> which parts of the new runtime are considered stable and which are
> not, so if we did this willy-nilly then we might end up using some of
> the "unstable" parts. And then in 2017 the Windows team does some
> internal refactoring and pushes it out through windows update and
> suddenly NumPy / R / Julia / git / ... all start segfaulting at
> startup on Windows, which would be a disaster from everyone's point of
> view. We've pointed this out to the Python team at Microsoft and
> they've promised to try and put Carl and the relevant mingw-w64 folks
> in touch with the relevant internal folks at MS to hopefully tell us
> how to do this correctly... fingers crossed :-).
>
> Aside from that, the main challenge for mingwpy in general is exactly
> the issue of upstream support: if we don't get the interop stuff
> pushed upstream from mingwpy to mingw-w64, then it will rot and break.
> And upstream would love to have this interoperability as an officially
> supported feature... but upstream doesn't consider what we have right
> now to be maintainable, so they won't take it as is. (And honestly,
> this is a reasonable opinion.) So what I've been trying to do is to
> scrounge up some funding to support Carl and upstream doing this right
> (the rough estimate is ~3 person-months of work).
>
> The original goal was to get MS to pay for this, on the theory that
> they should be cleaning up their own messes, but after 6 months of
> back-and-forth we've pretty much given up on that at this point, and
> I'm in the process of emailing everyone I can think of who might be
> convinced to donate some money to the cause. Maybe we should have a
> kickstarter or something, I dunno :-).
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecate fromstring() for text reading?

[Chris Barker - NOAA Federal]

I think it would be good to keep the usage to read binary data at least.


Agreed -- it's only the text file reading I'm proposing to deprecate. It
was kind of weird to cram it in there in the first place.

Oh, fromfile() has the same issues.

Chris


Or is there a good alternative to `np.fromstring(, dtype=...)`?  --
Marten

On Thu, Oct 22, 2015 at 1:03 PM, Chris Barker  wrote:

> There was just a question about a bug/issue with scipy.fromstring (which
> is numpy.fromstring) when used to read integers from a text file.
>
> https://mail.scipy.org/pipermail/scipy-user/2015-October/036746.html
>
> fromstring() is bugging and inflexible for reading text files -- and it is
> a very, very ugly mess of code. I dug into it a while back, and gave up --
> just to much of a mess!
>
> So we really should completely re-implement it, or deprecate it. I doubt
> anyone is going to do a big refactor, so that means deprecating it.
>
> Also -- if we do want a fast read numbers from text files function (which
> would be nice, actually), it really should get a new name anyway.
>
> (and the hopefully coming new dtype system would make it easier to write
> cleanly)
>
> I'm not sure what deprecating something means, though -- have it raise a
> deprecation warning in the next version?
>
> -CHB
>
>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] deprecate fromstring() for text reading?

[Chris Barker]

There was just a question about a bug/issue with scipy.fromstring (which is
numpy.fromstring) when used to read integers from a text file.

https://mail.scipy.org/pipermail/scipy-user/2015-October/036746.html

fromstring() is bugging and inflexible for reading text files -- and it is
a very, very ugly mess of code. I dug into it a while back, and gave up --
just to much of a mess!

So we really should completely re-implement it, or deprecate it. I doubt
anyone is going to do a big refactor, so that means deprecating it.

Also -- if we do want a fast read numbers from text files function (which
would be nice, actually), it really should get a new name anyway.

(and the hopefully coming new dtype system would make it easier to write
cleanly)

I'm not sure what deprecating something means, though -- have it raise a
deprecation warning in the next version?

-CHB





-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion