[matplotlib-devel] my $0.02 on MEP13
Hi, I saw that a discussion started on transitioning to the use of properties instead of explicit getters and setters, which seems like a very good idea to me... so I thought this would be a good idea to get involved in matplotlib-devel :) Right now an issue raised is what to do with set_* that take multiple arguments. Taking set_title, which takes both positional and keyword arguments, as an example, my idea would be to do ax.title = "A title" ax.title.fontdict = fontdict Basically, a property "foo" (in the matplotlib meaning of the word) becomes a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword arguments to the old property setter become themselves descriptors on that descriptor. Antony -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Financial support for continuous integration
On Wed, Jan 30, 2013 at 9:27 PM, Damon McDougall wrote: > On Wed, Jan 30, 2013 at 8:44 AM, Michael Droettboom wrote: >> In discussions with Perry Greenfield at STScI, it seems we are in the >> position of being able to get some financial support to pay for a >> continuous integration system. >> >> Travis has shown itself to be rather glitchy for matplotlib. The tight >> integration with Github PRs is really convenient. However, matplotlib >> has longer test runs and more dependencies than many projects. The >> frequent false positives start to wear down at a certain point. And we >> still aren't testing everything because we can't aren't installing >> Inkscape and other things in the Travis VM. >> >> So we're looking to add another paid, hosted continuous integration >> service that will better meet our needs. A hosted service is nice >> because it's easy to give multiple developers access to the system so >> anyone can tweak it and keep it going -- the bottleneck of a single >> developer responsible for maintenance of the build machine was a problem >> years ago when we were using buildbot. This may remain "in addition to" >> rather than "instead of" Travis for some time. >> >> An obvious first choice to me is ShiningPanda, as I have experience >> using it for astropy. Jenkins (the software Shining Panda is based on), >> is a really easy-to-use system, for those not familiar with it. And we >> can store the output of the tests (i.e. the result_images) for later >> inspection. I think this feature alone is huge for matplotlib. They >> also offer Windows build slaves. There is no OS-X (probably because >> Apple licensing doesn't really allow for use in a VM), but results can >> be "published" to their Jenkins instance. >> >> Are there any other similar alternatives we should consider before we >> move forward? >> >> Mike > > I think hosted infrastructure is the right choice. I was initially > going to suggest that we try and work with a bespoke solution. That > way we could roll our own build architectures. > > On reflection I think the maintenance headache of managing our own > build slaves outweighs the convenience of having it hosted, as you > point out. Of course, you're still going to need people who are willing/able to maintain OSX build slaves if you want to do testing on OSX (which obviously you should). It's easy with Jenkins to run your own instances and have it push results to the Shining Panda instance or any other hosted service. But otherwise you're back to square one in terms of having to rely on the people running the OSX builds. We've had this problem on Astropy in that I'm maintaining our current only Windows machine (ShingingPanda does have Windows support but a a cost) and so whenever the build bot itself breaks on Windows it's up to me to do anything about it. It also makes it hard for other admins to make tweaks to the build configuration. Unfortunately you're probably going to have that problem with OSX and probably Windows with any other hosted service as well. Erik -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee wrote: > Hi, > > I saw that a discussion started on transitioning to the use of properties > instead of explicit getters and setters, which seems like a very good idea > to me... so I thought this would be a good idea to get involved in > matplotlib-devel :) > > Right now an issue raised is what to do with set_* that take multiple > arguments. Taking set_title, which takes both positional and keyword > arguments, as an example, my idea would be to do > > ax.title = "A title" > ax.title.fontdict = fontdict > > Basically, a property "foo" (in the matplotlib meaning of the word) becomes > a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword > arguments to the old property setter become themselves descriptors on that > descriptor. Unfortunately descriptors don't really work like that, because when you do `.title` on an instance that doesn't return the descriptor itself, it just returns the result of `__get__` on the descriptor. So in your example `.fontdict` would have to be an attribute on any string assigned as the title. So what you really have to do for this to work is to wrap every value returned by the descriptor in some kind of proxy that adds the appropriate extra attributes. It also has to do so in a way that the proxy can behave transparently like the wrapped object, and that none of the wrapped objects attributes are overshadowed. And it has to hypothetically work with instances any any arbitrary type or class. While this is somewhat doable for a limited set cases it's really more of a can of worms than it's worth. Believe me, I've tried to solve similar problems to this one before. A couple easier solutions: Allow the `.title` (and other such attributes) to be assigned to with a (value, options) tuple where the value is the title itself, and the options is a dictionary or tuple of supported options for the title. Another solution is to just keep set_title() for cases like this if one wishes to set the title with additional options (while still allowing `.title = 'foo'` for the simple case). -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On 2/7/13 8:08 PM, Erik Bray wrote: > A couple easier solutions: Allow > the `.title` (and other such attributes) to be assigned to with a > (value, options) tuple where the value is the title itself, and the > options is a dictionary or tuple of supported options for the title. Interesting. Just brainstorming here...then ax.title += (None, moreoptions) could set more options (without changing the title text or already set options), or ax.title -= (None, deleteoptions) could reset just certain options to default values. Thanks, Jason -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
