The short answer: yes, we can and we should. I had that on my radar for a while too, because it felt un-Pythonic.
As for deprecation, there's no specific rule for the Python client yet. I'm happy to accept a patch for it for e.g. a version of the client 1.4.0 with an announcement that support for these getters/setters will be removed in said version. I'm not a fan of removing things in patch versions myself, but that's certainly up for discussion. The Python client is quite old and has come a long way, so I'm all for getting rid of the cruft that came with it. Cheers, Mathias On Mittwoch, 14. September 2011 at 13:30, Greg Stein wrote: > 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 (mailto:riak-users@lists.basho.com) > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
