Re: [Numpy-discussion] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

[Joseph Fox-Rabinovitz]

Where can I find the output of the tests on GitHub? I seem to be having 
trouble locating them.
-Joe
Sent from my LG Optimus L70™


-- Original message--From: Jaime Fernández del RíoDate: Thu, Jan 21, 
2016 02:17To: Discussion of Numerical Python;Subject:Re: [Numpy-discussion] PR 
#7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogramThe tests are 
not passing, seems like you are taking the sqrt of a negative number, may want 
to check the inputs and raise a more informative error (and add a test for it).
Jaime
On Thu, Jan 21, 2016 at 7:51 AM, Joseph Fox-Rabinovitz 
 wrote:
Please let me know if there is anything wrong or missing. I have added
a couple of estimators that I find useful sometimes.

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



-- 
(__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de 
dominación mundial.___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Sebastian Berg]

On Do, 2016-01-21 at 09:38 +, Robert Kern wrote:
> On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
> >
> > On Di, 2016-01-19 at 16:28 +, G Young wrote:
> > > In rand range, it raises an exception if low >= high.
> > >
> > > I should also add that AFAIK enforcing low >= high with floats is
> a
> > > lot trickier than it is for integers.  I have been knee-deep in
> > > corner cases for some time with randint where numbers that are
> > > visually different are cast as the same number by numpy due to
> > > rounding and representation issues.  That situation only gets
> worse
> > > with floats.
> > >
> >
> > Well, actually random.uniform docstring says:
> >
> > Get a random number in the range [a, b) or [a, b] depending on
> > rounding.
> 
> Which docstring are you looking at? The current one says [low, high)
> 

Sorry, I was referring to the python random.uniform function. And as
far as I now understand the current numpy equivalent (intentionally or
not) seems to do the same thing, which suits fine with me.

- Sebastian



> http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.unif
> orm.html#numpy.random.uniform
> 
> --
> Robert Kern
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Robert Kern]

On Thu, Jan 21, 2016 at 7:06 AM, Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
>
> There doesn't seem to be much of a consensus on the way to go, so leaving
things as they are and have been seems the wisest choice for now, thanks
for all the feedback. I will work with Greg on documenting the status quo
properly.

Ugh. Be careful in documenting the way things currently work. No one
intended for it to work that way! No one should rely on high___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Behavior of np.random.uniform

[Robert Kern]

On Tue, Jan 19, 2016 at 5:35 PM, Sebastian Berg 
wrote:
>
> On Di, 2016-01-19 at 16:28 +, G Young wrote:
> > In rand range, it raises an exception if low >= high.
> >
> > I should also add that AFAIK enforcing low >= high with floats is a
> > lot trickier than it is for integers.  I have been knee-deep in
> > corner cases for some time with randint where numbers that are
> > visually different are cast as the same number by numpy due to
> > rounding and representation issues.  That situation only gets worse
> > with floats.
> >
>
> Well, actually random.uniform docstring says:
>
> Get a random number in the range [a, b) or [a, b] depending on
> rounding.

Which docstring are you looking at? The current one says [low, high)

http://docs.scipy.org/doc/numpy/reference/generated/numpy.random.uniform.html#numpy.random.uniform

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

Re: [Numpy-discussion] Should I use pip install numpy in linux?

[Robert McGibbon]

Hi all,

Just as a heads up: Nathaniel and I wrote a draft PEP on binary linux
wheels that is now being discussed on distutils-sig, so you can check that
out and participate in the conversation if you're interested.

- PEP on python.org: https://www.python.org/dev/peps/pep-0513/
- PEP on github with some typos fixed:
https://github.com/manylinux/manylinux/blob/master/pep-513.rst
- Email archive:
https://mail.python.org/pipermail/distutils-sig/2016-January/027997.html

-Robert

On Tue, Jan 19, 2016 at 10:05 AM, Ralf Gommers 
wrote:

>
>
> On Tue, Jan 19, 2016 at 5:57 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>>
>> > 2) continue to support those users fairly poorly, and at substantial
>> > ongoing cost
>>
>> I'm curious what the cost is for this poor support -- throw the source
>> up on PyPi, and we're done. The cost comes in when trying to build
>> binaries...
>>
>
> I'm sure Nathaniel means the cost to users of failed installs and of numpy
> losing users because of that, not the cost of building binaries.
>
> > Option 1 would require overwhelming consensus of the community, which
>> > for better or worse is presumably not going to happen while
>> > substantial portions of that community are still using pip/PyPI.
>>
>> Are they? Which community are we talking about? The community I'd like
>> to target are web developers that aren't doing what they think of as
>> "scientific" applications, but could use a little of the SciPy stack.
>> These folks are committed to pip, and are very reluctant to introduce
>> a difficult dependency.  Binary wheels would help these folks, but
>> that is not a community that exists yet ( or it's small, anyway)
>>
>> All that being said, I'd be happy to see binary wheels for the core
>> SciPy stack on PyPi. It would be nice for people to be able to do a
>> bit with Numpy or pandas, it MPL, without having to jump ship to a
>> whole new way of doing things.
>>
>
> This is indeed exactly why we need binary wheels. Efforts to provide those
> will not change our strong recommendation to our users that they're better
> off using a scientific Python distribution.
>
> Ralf
>
>
> ___
> 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] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

[Joseph Fox-Rabinovitz]

I fixed the issue by checking if x.size > 2 before the calculation. An
error should never need to be raised at that point. The build passes
now and the results appear to be correct.

On Thu, Jan 21, 2016 at 2:17 AM, Jaime Fernández del Río
 wrote:
> The tests are not passing, seems like you are taking the sqrt of a negative
> number, may want to check the inputs and raise a more informative error (and
> add a test for it).
>
> Jaime
>
> On Thu, Jan 21, 2016 at 7:51 AM, Joseph Fox-Rabinovitz
>  wrote:
>>
>> Please let me know if there is anything wrong or missing. I have added
>> a couple of estimators that I find useful sometimes.
>>
>> -Joe
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de
> dominación mundial.
>
> ___
> 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] PR #7083: ENH: Added 'doane' and 'sqrt' estimators to np.histogram

[Joseph Fox-Rabinovitz]

Due to a mistake I made in my branch structure, I have replaced this
PR with #7090: https://github.com/numpy/numpy/pull/7090. All of the
changes and fixes so far are squashed into the new request.

-Joe

On Thu, Jan 21, 2016 at 1:51 AM, Joseph Fox-Rabinovitz
 wrote:
> Please let me know if there is anything wrong or missing. I have added
> a couple of estimators that I find useful sometimes.
>
> -Joe
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

[Nathaniel Smith]

On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg
 wrote:
> Hi all,
>
> should we try to set FutureWarnings to errors in dev tests? I am
> seriously annoyed by FutureWarnings getting lost all over for two
> reasons. First, it is hard to impossible to find even our own errors
> for our own FutureWarning changes. Secondly, we currently would not
> even see any Futurewarnings from someone else. For numpy that may not
> be a big issue, but still.

Yeah, I noticed this recently too :-(. Definitely it is the right
thing to do, I think. And this is actually more true the more annoying
it is, because if we're triggering lots of FutureWarnings then we
should fix that :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Set FutureWarnings to error in (dev) tests?

[Sebastian Berg]

Hi all,

should we try to set FutureWarnings to errors in dev tests? I am
seriously annoyed by FutureWarnings getting lost all over for two
reasons. First, it is hard to impossible to find even our own errors
for our own FutureWarning changes. Secondly, we currently would not
even see any Futurewarnings from someone else. For numpy that may not
be a big issue, but still.

So, I was starting to try it, and it is annoying obviously. The only
serious issue, though, seems actually MA [1].
Sometimes one would add a filter for a whole test file (for my start I
did this for the NaT stuff) [2].

Anyway, should we attempt to do this? I admit that trying to make it
work, even *with* the change FutureWarnings suddenly pop up when you
make the warnings being given less often (I will guess that warning was
already issued at import time somewhere).

- Sebastian


[1] And at that a brand new future warning there, which seems too
agressive in any case, though that won't change much.

[2] One annoying thing about this, the filter might never be removed.
One could add a canary maybe to error out when the filter is not needed
anymore.

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] deprecating assignment to ndarray.data

[Nathaniel Smith]

So it turns out that ndarray.data supports assignment at the Python
level, and what it does is just assign to the ->data field of the
ndarray object:
   
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/getset.c#L325

This kind of assignment been deprecated at the C level since 1.7, and
is totally unsafe -- if there are any views pointing to the array when
this happens, then they'll be left pointing off into unallocated
memory.

E.g.:

a = np.arange(10)
b = np.linspace(0, 1, 10)
c = a.view()
a.data = b.data
# Now c points into free'd memory

Can we deprecate or just remove this?

(Also filed issue: https://github.com/numpy/numpy/issues/7093)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

[Nathaniel Smith]

Warnings filters can be given a regex matching the warning text, I think?
On Jan 21, 2016 5:00 PM, "Sebastian Berg" 
wrote:

> On Do, 2016-01-21 at 16:51 -0800, Nathaniel Smith wrote:
> > On Thu, Jan 21, 2016 at 4:44 PM, Sebastian Berg
> >  wrote:
> > > On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote:
> > > > On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg
> > > >  wrote:
> > > > > Hi all,
> > > > >
> > > > > should we try to set FutureWarnings to errors in dev tests? I
> > > > > am
> > > > > seriously annoyed by FutureWarnings getting lost all over for
> > > > > two
> > > > > reasons. First, it is hard to impossible to find even our own
> > > > > errors
> > > > > for our own FutureWarning changes. Secondly, we currently would
> > > > > not
> > > > > even see any Futurewarnings from someone else. For numpy that
> > > > > may
> > > > > not
> > > > > be a big issue, but still.
> > > >
> > > > Yeah, I noticed this recently too :-(. Definitely it is the right
> > > > thing to do, I think. And this is actually more true the more
> > > > annoying
> > > > it is, because if we're triggering lots of FutureWarnings then we
> > > > should fix that :-).
> > > >
> > >
> > > Yeah, the problem is that some FutureWarnings that are given in the
> > > dozens. Injecting the filter on the module level is possible, but
> > > not
> > > quite correct. Maybe one could do evil things similar to a "module
> > > decorator" to add the warning context + filter to every single
> > > function
> > > in a module starting with "test_".
> >
> > Can we remove the FutureWarnings by making whatever change they're
> > warning about? :-)
> >
>
> That would be equivalent of not issueing the futurewarning at all ;).
> Well, you can write a context manager and put this stuff into the
>
> if __name__ == '__main__':
>
> block actually. It is still annoying, since ideally we want to filter a
> single warning, which means the necessaty to install our own warning
> printer.
>
>
> > > Another method could be to abuse `__warningregistry__`, but there
> > > are
> > > at least two reasons why this is probably not viable (nevermind
> > > that it
> > > would be ugly as well).
> > >
> > > Doesn't nose maybe provide *something*? I mean seriously, testing
> > > warnings tends to be hell broke lose? Change one thing, suddenly
> > > dozens
> > > appear from nowhere, never sure you found all cases, etc.
> >
> > AFAICT nose doesn't provide much of anything for working with
> > warnings. :-/
> >
> > -n
> >
> ___
> 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] Set FutureWarnings to error in (dev) tests?

[Sebastian Berg]

On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote:
> On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg
>  wrote:
> > Hi all,
> > 
> > should we try to set FutureWarnings to errors in dev tests? I am
> > seriously annoyed by FutureWarnings getting lost all over for two
> > reasons. First, it is hard to impossible to find even our own
> > errors
> > for our own FutureWarning changes. Secondly, we currently would not
> > even see any Futurewarnings from someone else. For numpy that may
> > not
> > be a big issue, but still.
> 
> Yeah, I noticed this recently too :-(. Definitely it is the right
> thing to do, I think. And this is actually more true the more
> annoying
> it is, because if we're triggering lots of FutureWarnings then we
> should fix that :-).
> 

Yeah, the problem is that some FutureWarnings that are given in the
dozens. Injecting the filter on the module level is possible, but not
quite correct. Maybe one could do evil things similar to a "module
decorator" to add the warning context + filter to every single function
in a module starting with "test_".

Another method could be to abuse `__warningregistry__`, but there are
at least two reasons why this is probably not viable (nevermind that it
would be ugly as well).

Doesn't nose maybe provide *something*? I mean seriously, testing
warnings tends to be hell broke lose? Change one thing, suddenly dozens
appear from nowhere, never sure you found all cases, etc.

- Sebastian


> -n
> 

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

[Sebastian Berg]

On Do, 2016-01-21 at 17:07 -0800, Nathaniel Smith wrote:
> Warnings filters can be given a regex matching the warning text, I
> think?

Doesn't cut it, because you need to set the warning to "always", so
then if you don't want to print it, you are stuck

I wrote a context manager + func decorator + class decorator, which can
do it (it overrides how the warning gets printed). Still got to
decorate every weird test or at least test class, or escalate it to the
global level. Needs some more, but that suppression functionality (in
what exact form it could be in the end), is much more reasonable then
our typical warning context, since that drops even printing (though
since we would use Error during development it should not matter much).

The stuff is basically a safe version of:
with warnings.catch_warnings():
warnings.filterwarnings("ignore", )  # oh noe not ignore!

which also still prints other warnings.

- sebastian


> On Jan 21, 2016 5:00 PM, "Sebastian Berg"  > wrote:
> > On Do, 2016-01-21 at 16:51 -0800, Nathaniel Smith wrote:
> > > On Thu, Jan 21, 2016 at 4:44 PM, Sebastian Berg
> > >  wrote:
> > > > On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote:
> > > > > On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg
> > > > >  wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > should we try to set FutureWarnings to errors in dev tests?
> > I
> > > > > > am
> > > > > > seriously annoyed by FutureWarnings getting lost all over
> > for
> > > > > > two
> > > > > > reasons. First, it is hard to impossible to find even our
> > own
> > > > > > errors
> > > > > > for our own FutureWarning changes. Secondly, we currently
> > would
> > > > > > not
> > > > > > even see any Futurewarnings from someone else. For numpy
> > that
> > > > > > may
> > > > > > not
> > > > > > be a big issue, but still.
> > > > >
> > > > > Yeah, I noticed this recently too :-(. Definitely it is the
> > right
> > > > > thing to do, I think. And this is actually more true the more
> > > > > annoying
> > > > > it is, because if we're triggering lots of FutureWarnings
> > then we
> > > > > should fix that :-).
> > > > >
> > > >
> > > > Yeah, the problem is that some FutureWarnings that are given in
> > the
> > > > dozens. Injecting the filter on the module level is possible,
> > but
> > > > not
> > > > quite correct. Maybe one could do evil things similar to a
> > "module
> > > > decorator" to add the warning context + filter to every single
> > > > function
> > > > in a module starting with "test_".
> > >
> > > Can we remove the FutureWarnings by making whatever change
> > they're
> > > warning about? :-)
> > >
> > 
> > That would be equivalent of not issueing the futurewarning at all
> > ;).
> > Well, you can write a context manager and put this stuff into the
> > 
> > if __name__ == '__main__':
> > 
> > block actually. It is still annoying, since ideally we want to
> > filter a
> > single warning, which means the necessaty to install our own
> > warning
> > printer.
> > 
> > 
> > > > Another method could be to abuse `__warningregistry__`, but
> > there
> > > > are
> > > > at least two reasons why this is probably not viable (nevermind
> > > > that it
> > > > would be ugly as well).
> > > >
> > > > Doesn't nose maybe provide *something*? I mean seriously,
> > testing
> > > > warnings tends to be hell broke lose? Change one thing,
> > suddenly
> > > > dozens
> > > > appear from nowhere, never sure you found all cases, etc.
> > >
> > > AFAICT nose doesn't provide much of anything for working with
> > > warnings. :-/
> > >
> > > -n
> > > 
> > ___
> > 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

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

[Nathaniel Smith]

On Thu, Jan 21, 2016 at 4:44 PM, Sebastian Berg
 wrote:
> On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote:
>> On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg
>>  wrote:
>> > Hi all,
>> >
>> > should we try to set FutureWarnings to errors in dev tests? I am
>> > seriously annoyed by FutureWarnings getting lost all over for two
>> > reasons. First, it is hard to impossible to find even our own
>> > errors
>> > for our own FutureWarning changes. Secondly, we currently would not
>> > even see any Futurewarnings from someone else. For numpy that may
>> > not
>> > be a big issue, but still.
>>
>> Yeah, I noticed this recently too :-(. Definitely it is the right
>> thing to do, I think. And this is actually more true the more
>> annoying
>> it is, because if we're triggering lots of FutureWarnings then we
>> should fix that :-).
>>
>
> Yeah, the problem is that some FutureWarnings that are given in the
> dozens. Injecting the filter on the module level is possible, but not
> quite correct. Maybe one could do evil things similar to a "module
> decorator" to add the warning context + filter to every single function
> in a module starting with "test_".

Can we remove the FutureWarnings by making whatever change they're
warning about? :-)

> Another method could be to abuse `__warningregistry__`, but there are
> at least two reasons why this is probably not viable (nevermind that it
> would be ugly as well).
>
> Doesn't nose maybe provide *something*? I mean seriously, testing
> warnings tends to be hell broke lose? Change one thing, suddenly dozens
> appear from nowhere, never sure you found all cases, etc.

AFAICT nose doesn't provide much of anything for working with warnings. :-/

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Set FutureWarnings to error in (dev) tests?

[Sebastian Berg]

On Do, 2016-01-21 at 16:51 -0800, Nathaniel Smith wrote:
> On Thu, Jan 21, 2016 at 4:44 PM, Sebastian Berg
>  wrote:
> > On Do, 2016-01-21 at 16:15 -0800, Nathaniel Smith wrote:
> > > On Thu, Jan 21, 2016 at 4:05 PM, Sebastian Berg
> > >  wrote:
> > > > Hi all,
> > > > 
> > > > should we try to set FutureWarnings to errors in dev tests? I
> > > > am
> > > > seriously annoyed by FutureWarnings getting lost all over for
> > > > two
> > > > reasons. First, it is hard to impossible to find even our own
> > > > errors
> > > > for our own FutureWarning changes. Secondly, we currently would
> > > > not
> > > > even see any Futurewarnings from someone else. For numpy that
> > > > may
> > > > not
> > > > be a big issue, but still.
> > > 
> > > Yeah, I noticed this recently too :-(. Definitely it is the right
> > > thing to do, I think. And this is actually more true the more
> > > annoying
> > > it is, because if we're triggering lots of FutureWarnings then we
> > > should fix that :-).
> > > 
> > 
> > Yeah, the problem is that some FutureWarnings that are given in the
> > dozens. Injecting the filter on the module level is possible, but
> > not
> > quite correct. Maybe one could do evil things similar to a "module
> > decorator" to add the warning context + filter to every single
> > function
> > in a module starting with "test_".
> 
> Can we remove the FutureWarnings by making whatever change they're
> warning about? :-)
> 

That would be equivalent of not issueing the futurewarning at all ;).
Well, you can write a context manager and put this stuff into the

if __name__ == '__main__':

block actually. It is still annoying, since ideally we want to filter a
single warning, which means the necessaty to install our own warning
printer.


> > Another method could be to abuse `__warningregistry__`, but there
> > are
> > at least two reasons why this is probably not viable (nevermind
> > that it
> > would be ugly as well).
> > 
> > Doesn't nose maybe provide *something*? I mean seriously, testing
> > warnings tends to be hell broke lose? Change one thing, suddenly
> > dozens
> > appear from nowhere, never sure you found all cases, etc.
> 
> AFAICT nose doesn't provide much of anything for working with
> warnings. :-/
> 
> -n
> 

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating assignment to ndarray.data

[Juan Nunez-Iglesias]

Does this apply in any way to the .data attribute in scipy.sparse matrices?
I fiddle with that quite often!

On Fri, Jan 22, 2016 at 11:21 AM, Nathaniel Smith  wrote:

> So it turns out that ndarray.data supports assignment at the Python
> level, and what it does is just assign to the ->data field of the
> ndarray object:
>
> https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/getset.c#L325
>
> This kind of assignment been deprecated at the C level since 1.7, and
> is totally unsafe -- if there are any views pointing to the array when
> this happens, then they'll be left pointing off into unallocated
> memory.
>
> E.g.:
>
> a = np.arange(10)
> b = np.linspace(0, 1, 10)
> c = a.view()
> a.data = b.data
> # Now c points into free'd memory
>
> Can we deprecate or just remove this?
>
> (Also filed issue: https://github.com/numpy/numpy/issues/7093)
>
> -n
>
> --
> Nathaniel J. Smith -- https://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] deprecating assignment to ndarray.data

[Nathaniel Smith]

On Jan 21, 2016 6:17 PM, "Juan Nunez-Iglesias"  wrote:
>
> Does this apply in any way to the .data attribute in scipy.sparse
matrices?

Nope!

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

[Numpy-discussion] ANN: xarray (formerly xray) v0.7.0 released

[Stephan Hoyer]

I am pleased to announce version v0.7.0 of xarray, the project formerly
known as xray.

xarray is an open source project and Python package that aims to bring the
labeled data power of pandas to the physical sciences, by providing
N-dimensional variants of the core pandas data structures. These data
structures are based on the data model of the netCDF file format.

In this latest release, we have renamed the project from "xray" to
"xarray". This avoids a namespace conflict with the entire field of X-ray
science. We have new URLs for our documentation, source code and mailing
list:
http://xarray.pydata.org/
http://github.com/pydata/xarray/
https://groups.google.com/forum/#!forum/xarray

Highlights of this release:

* An internal refactor of DataArray internals
* New methods for reshaping, rolling and shifting data
* Preliminary support for pandas.MultiIndex
* Support for reading GRIB, HDF4 and other file formats via PyNIO

For more details, read the full release notes:
http://xarray.pydata.org/en/stable/whats-new.html

Contributors to this release:

Antony Lee
Fabien Maussion
Joe Hamman
Maximilian Roos
Stephan Hoyer
Takeshi Kanmae
femtotrader

I'd also like to highlight the contributions of Clark Fitzgerald, who added
a plotting module to xray in v0.6, and Dave Brown, for his assistance
adding PyNIO support.

Best,
Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] deprecating assignment to ndarray.data

[Jonathan J. Helmus]

On 1/21/2016 8:32 PM, Nathaniel Smith wrote:


> Does this apply in any way to the .data attribute in scipy.sparse 
matrices?


Nope!

-n



How about the .data attribute of masked arrays?  I'm guessing there may 
be a decent amount of code that uses array.data to try to duck-type 
ndarrays and MaskedArrays even though there are better ways to do 
this,   for example np.ma.getdata.


Cheers,

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