I will get to the documentation changes later.

Still haven't gotten to the documentation changes. I've been kinda crazy the last month or so.

@NelleV It looks like none of the functions in this file are the numpy style, should I do just the functions I touched, or would it be better to make a different PR with all of the documentation fixed?

@mdboom This is a API change and should probably go in 1.3 if it is going to go in.

@tacaswell: Thanks. It should get an entry inwhats_new andapi_changes and a test (probably doesn't need an image comparison test) and then I think it's good to go.

Going over this again last night I noticed some additional subtle api changes that I had missed before. The expected order of elements a nested sequence are also changed from [(d, open, close, high, low, ...), ...] -> [(d, open, high, low, close, ...), ...]. This affects the return values of the yahoo related functions and any of the functions that takequotes as an argument. Should all of these functions have*_ochl and*_ohlc versions created as well?

What sort of test should this get if not an image comparison? I don't think anything in this file is currently tested in anyway.

need to merge PR#2077 into this branch

(mostly a note to my self so I can find it again later)

Now that I have touched basically every function in this module, what tests should I add?

Should I smash most of these commits down to one?

@NelleV How should I deal with the very long URL on line 395?

@NelleVhttps://github.com/NelleV How should I deal with the very long
URL on line 395?

It seem to be a string, hence you can split it as you would split a string:
urlname = ("blah" +
"blah")

or
urlname = ("blah"
"blah")

there has been discussion on python-dev on removing the latter, so I would
go with the splitting with the + sign.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1920#issuecomment-18661681
.

@dmcdougall Now that things have calmed down a bit can this get some attention?

I don't want to interfere with all the work that has gone into trying to straighten out this module, but it raises a larger question: should such a specialized module even be part of the mpl core distribution? I think the answer is clearly "no". It should be in an external toolkit, or an example, or a cookbook, but it should not be accessible via "from matplotlib import ...".

In response to@efiring: I agree, this is highly specialized, and long term should probably be (at least) be moved tompl_toolkits, or even better to its own independent project. But there are a lot of other things in matplotlib in that boat and I'd rather devise a plan for outward migration that works well for all such things. I don't think we should let that hold up this pull request which is valuable improvement in any event.

@tacaswell: Can you rebase so that the diff is clean again and we can go through for a (hopefully last) round of reviews?

Currently traveling, I will get to this over the weekend.

I have no protest to this getting pulled out.

Tom
On Jul 16, 2013 5:22 PM, "Michael Droettboom"notifications@github.com
wrote:

In response to@efiringhttps://github.com/efiring: I agree, this is
highly specialized, and long term should probably be (at least) be moved to
mpl_toolkits, or even better to its own independent project. But there
are a lot of other things in matplotlib in that boat and I'd rather devise
a plan for outward migration that works well for all such things. I don't
think we should let that hold up this pull request which is valuable
improvement in any event.

@tacaswellhttps://github.com/tacaswell: Can you rebase so that the
diff is clean again and we can go through for a (hopefully last) round of
reviews?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1920#issuecomment-21074865
.

I don't understand the errors coming out of travis, two of them look likeAttributeErrors coming out of nose and the third is a font issue.

👍 from me. Thanks for all of your hard work on this!

The travis failures are unrelated, because this module has no test coverage.

As near as I can tell, the documentation for this module is not generated by sphinx.

I added it to the api list, but this seems at cross purposes to pulling this module out ofmatplotlib proper.

I think as long as it's in matplotlib, it should probably be in the documentation. Maybe just add a module-level docstring (which would also appear in the HTML docs), that says this module is deprecated?