[matplotlib-devel] Sankey code review
Hello, I would like to ask for a code review on the Sankey feature. I've tried to improve the formatting and documentation. Here is the comparison: https://github.com/kdavies4/matplotlib/compare/master...sankey3#diff-1 Thanks! Kevin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Sankey documentation missing in v1.1?
Hello, I don't think the web documentation is showing up for the new Sankey diagram class. I probably failed to hook it in somehow. Could someone please take a look? The file that would have produced the documentation is matplotlib/lib/matplotlib/sankey.py. I expected it would show up at http://matplotlib.sourceforge.net/api/sankey_api.html, but there's no such page. The Sankey demos did show up on the examples page and in the gallery. Also, the overview showed up in the "what's new" page. Thanks. Kevin -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] request for code review: updates to Sankey class
Hello, I made a few minor changes to the Sankey class. They are listed at: https://github.com/kdavies4/matplotlib/compare/master...sankey5 Please review this and let me know if I can submit a pull request. Thanks. Kevin -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] request for code review: updates to Sankey class
Thanks for your comments! see below... On 10/16/2012 10:14 AM, Damon McDougall wrote: > On Tue, Oct 16, 2012 at 2:55 PM, Kevin Davies wrote: >> Hello, >> >> I made a few minor changes to the Sankey class. They are listed at: >> https://github.com/kdavies4/matplotlib/compare/master...sankey5 >> >> Please review this and let me know if I can submit a pull request. >> >> Thanks. >> >> Kevin > Thanks for taking the time to fix up a part of the codebase! > > If you make a pull request out of your code, we'll be able to leave > inline comments on your patches. Nonetheless, I have some feedback for > you after a (very) quick glance: I submitted the pull request. > 1) I don't think 'orientations' is a python keyword. What is the error > you were getting? In any case, changing it breaks backwards > compatibility so I'd be an advocate of keeping 'orientations'. Unless, > of course, the error you were getting was serious. The problem was on my end (In my code, I intercepted orientations as a named argument but assumed it being passed through **kwargs). I reverted to the original. Thanks for your patience. I'm sorry. > 2) Your changes appear to be, mainly, cosmetic. This is good but may > cause issues with some of the PEP8 pull requests we have been getting. > Have you rebased to make sure these changes are incorporated? I rebased off master after pulling from origin. That's correct, right? > 3) Inline with my PEP8 remark in 2) above. You have some lines (maybe > only one or two) that look longer than 79 characters. I re-wrapped everything to 79 characters. > Other than that, I think you should turn this into a pull request so > you can get more feedback on an interactive level. > > Best, > Damon > -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc
Regarding whole sets of rcParams, you may want to look at this:
https://github.com/tonysyu/mpltools
Kevin
On 07/20/2013 09:48 PM, Chris Beaumont
wrote:
'image.cmap' -- nice! Shows how much I know :)
I don't fully agree with Eric that changing the defaults
should be treated as an API break -- yes, it may irritate a
minority of users, but their code will still run. I'd flip
around your argument for the role of rcParams and
customization: the majority user is probably someone who
doesn't know much about rcParams, or all the ways plots can be
customized. *That* is the use case to optimize, not the
"legacy" users invested in the current style.
However, default tweaking need not be painful. As has been
mentioned, a first step would be an easier way to change a
whole set of rcParams: something like
mpl.set_style('style-name'). As long as one style is
'classic', users can keep the current style for as long as
they want. It's a one line fix, and could even be
rcParams-settable.
With such a framework, it would be possible for people to
contribute new styles that ship with MPL, and users could
change styles without having to find (and potentially merge)
rcParams files from the web. Finally, people could nominate
that mature styles be made default (you could even assign
version numbers to track the default style as it evolves
towards visual awesomeness)
chris
On Sat, Jul 20, 2013 at 9:07 PM, Eric
Firing
wrote:
On 2013/07/20 2:38 PM, David P. Sanders
wrote:
> And this is my problem with 'rc': it brings to mind
an arcane config
> file hidden away somewhere that has a terrible syntax
and must not be
> touched.
>
> As Chris and Adrian have emphasized, the point is
that we *should* be
> tweaking away at the parameters all the time.
> I propose to rename as mpl_params=rcParams
>
Yes, mpl_params is more descriptive and easy to remember.
rcParams is
ugly, obscure, and archaic. It will have to remain
available for a long
time, but I don't object to changing standard usage to a
nicer name.
There might even be a better name than
"mpl_params"--"settings" comes to
mind, or maybe "style".
As for parameter tweaking: the defaults shipped with mpl
should be
changed only rarely, but we should make it as easy as
possible for users
to customize plots, including coming up with good
combinations of style
parameters. In some cases it makes sense to do this via a
matplotlibrc
file, in other cases it is better to do the parameter
setting explicitly
at the top of a script.
Regarding defaults, note that I said "rarely", not "never".
The whole rc system could use a good review--maybe resulting
in lots of
changes, maybe not--so I welcome the attention you are
directing to it.
Eric
--
See everything from the browser to the database with
AppDynamics
Get end-to-end visibility with application monitoring
from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
--
