Hi all, There are some non-Pythonic patterns in riak-python-client that should be pretty easy to switch. Things like client.get_r() and client.set_r() are kinda silly. Python long ago moved past the getter/setter paradigm, with the notion of directly exposing instance attributes. As Guido has said numerous times, "we're all adults here", so we don't need to wrap simple attribute access/change in methods which do exactly that anyways. Just allow apps to directly change it, since the developers doing that *are* adults and know what they're doing.
For something like bucket.get_r()... first: it should not have a damned argument that is returned if you pass in a value. That is nonsense. Don't call the function if you're going to pass an argument! The remaining logic looks at a local value, or defers to the client default value. We can make "bucket.r" a property, and create a getter that does the right thing. Applications can then use "bucket.r" and they will get the right logic, rather than the messier "bucket.get_r()". There are similar changes throughout (eg. get_transport). But... this goes back to a question that I've raised earlier: what kinds of API guarantees are being made on the interface? Can we simply get rid of the .get_r() method? If we choose to do so, is there a deprecation policy? With a policy in place, then it would be easier for me (and others) to provide patches, knowing that they conform to compatibility requirements. As it stands, I'd be happy to code a patch, but am wary that my effort would be rejected per some (unstated) policy. I don't know how much of a compatibility policy lies with Basho or the community. Dunno how to help there. And back to the start: can we get the code simplified, and move towards properties? Cheers, -g _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
