On 14 Sep 2011, at 12:37, Mathias Meyer 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.
I'd really like to see the python client be more pythonic. That said, I'd really like current production users to keep running their code, and take advantage of new features without recoding their use of existing features. For the Java client I've deprecated a lot of the API, but it will stay on for a couple of releases. No-one likes living with warts on software but deprecating is a good way to show that the un-idiomatic stuff is on the way out, without pulling the rug from under users. > 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. > Me too, but after it has been deprecated for at least one release? That isn't an official policy, it is just the one I have set for the Java client. Deprecate for one release, remove in the next. Does that sound reasonable for the Python client, too? Cheers Russell > 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 >> [email protected] (mailto:[email protected]) >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
