Riak 1.0 is coming soon. Perhaps it makes sense for client point releases to coincide with server point releases?
- Kev c: +001 (650) 521-7791 On Wed, Sep 14, 2011 at 4:37 AM, Mathias Meyer <me...@paperplanes.de> wrote: > 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 >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
