rebased.

Also addresses#5557

besides the nitpicking, this looks good to me

@WeatherGod do you want me to drop that (some what superfluous) white space commit?

Eh, might be better to get rid of that commented out code entirely. I don't see the point of keeping it around.

Well, the minimum numpy is now 1.6 so we should do what ever it was that note was telling us to do.

?

The comment below the commented line says that we are handlingnormed internally until our minimum version of numpy can handle it (which the comment claims in > 1.5). I think it will take a bit of work (at least for met) to understand how what we are currently doing works to make sure that we can just fall over to numpy.

Ah, yeah, that comment (I must be getting blind...). I suspect that it is quite old and came from before the days that stacked histograms and such were possible. I am not sure it is possible to just hand off the responsibility of norming to numpy any more given the current feature set.

This is passing and not conflicting, can someone push the button on this before it needs another rebase 😈 .

I do have another concern with respect to generators. Previously, generators just simply didn't work, now they may sort of work (generator gets partly consumed). This muddles the API a bit. Wouldn't it be better to detect that we have a generator and raise an error? We can later consider how to properly support generators without consuming them.

That is a can of worms of handling I am worried about opening and would rather punt on the whole thing. This at least does notbreak any existing user code.

isn't it just simply a matter of testingisinstance(x, collections.Iterator)? That would be false for lists, numpy arrays and such, but should be true for generators and iterators, I think.

I am more worried about applying that test uniformly across the library.

That would be nice, but it is not the goal that I am seeking. Simply that we add this test where-ever we have code that would potentially consume an iterator. That way, the API hasn't changed. So, that is just two places here in this PR.

fair enough

Digging into this a bit (and trying to sort out whyplot does not have this problem) it turns out thatplot goes through an entirely different code path by usingAxis.update_units which delegates tounits.Registry.get_convertor which has some non-trivial logic and will do very bad things to generators (I think).

This PR is a whack-a-mole fix which will get 1.5.1 out the door.

The test failure is un-related (due to backport of custom RNG).

seems like it, was the baseline images not updated for the new RNG?

seems like it, was the baseline images not updated for the new RNG?

They were. This looks like a "only on Travis" sort of failure.

That doesn't give me any sort of warm fuzzies...

I can reproduce it locally (but it passedbefore I pushed upstream (which I assume means my local install had become screwed up)).

I hope this hasn't become another rabbit-infested dragon cave...

Looks like you cleared out the rabbits!

By moving a bit of the if-statement into a cbook function, the if-statement starts to be a little bit clearer. Probably would be a good idea to have some cbook tests at some point, but that can come later.