Maybe these new set functions should be implemented as properties so as not to change the interface?

This partly harkens back to an issue I have been mulling over in that there needs to be a common interface across all artists to get/set the "data" of the artist. And it should probably be implemented as properties so that each subclass of artist can trigger any other appropriate recalculations as needed.

Well, the common interface already exists in the getp and setp
functions. Sure, properties would be more pythonic, and I have little
love for getp and setp, but should we really add properties and thus
duplicate the "access points"? Of course I can do that if that's the
current "policy".

On Fri, Jan 04, 2013 at 06:19:52AM -0800, Benjamin Root wrote:

This partly harkens back to an issue I have been mulling over in that there needs to be a common interface across all artists to get/set the "data" of the artist. And it should probably be implemented as properties so that each subclass of artist can trigger any other appropriate recalculations as needed.

---

Reply to this email directly or view it on GitHub:
#1635 (comment)

What I mean is a common property/attribute name across all artists. Some artists call it "data", while others call it "vertices", and others call it "xy". I should note that this qualm of mine shouldn't hold up this PR. It just that this PR highlights my qualm. There is no current policy.

@WeatherGod: do you agree this is good to go -- despite your qualm, which I share?

It looks good to me. I see no reason not to take it. But it looks like it needs a rebase.

@anntzer : Would you mind rebasing your branch on the current master and repushing it to github?

Here we go.

Cheers for your time and hard work @anntzer!

Thanks for ninjaing all these PRs, @mdboom! Teamwork!