[13:50] <cjwatson> wgrant: Do you know if anyone's ever looked at making it easier to rename properties in Storm?  I'm considering writing a thing where you could say e.g. class Person: displayname = RenamedProperty("display_name"), with a __get__ method such that both Person.displayname and Person.display_name would DTRT in Storm queries
[13:51] <cjwatson> wgrant: It ought to be possible to give it a .setter like the one on the stdlib's property(), so that we could have a renamed property with a custom setter - useful for the Person.name work
[13:52] <cjwatson> Though in the latter case we kind of don't really want to rename it in an ideal world, it would be better to simply be able to set custom setters on storm properties
[14:15] <cjwatson> wgrant: Actually, I suppose you can effectively do custom setters (assuming that they end up storing a value at all) with a validator.  So do we actually need to do the Person.name renaming that you were talking about?
[22:36] <wgrant> cjwatson: Hm, did I suggest renaming Person.name?
[22:37] <wgrant> cjwatson: It needs to be significantly reworked due to the fact that it's impossible in some cases and involves API calls in others, but it doesn't obviously need to be renamed.
[22:37] <cjwatson> wgrant: Not renaming as such, but you were talking about putting a setter on it and seeing whether things still work
[22:37] <cjwatson> Which I was initially taking to mean renaming to _name and adding @property name
[22:37] <wgrant> Oh, no.
[22:37] <wgrant> I did that weeks ago with a validator and got it down to 13 broken tests.
[22:38] <cjwatson> Aha
[22:38] <cjwatson> I'd still like to explore easier property renaming, but in that case just not for this particular job
[22:39] <cjwatson> It's very annoying that renaming Person.displayname to Person.display_name entailed going through and hunting for Storm queries
[22:40] <wgrant> It is.