On Wed, Sep 14, 2011 at 10:40, Russell Brown <[email protected]> wrote: > > 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?
For at least three developers :-P ... there seems to be rough consensus here: * Documented APIs are first marked as "deprecated" in documentation/docstrings, and will produce appropriate warnings from the code (but remain available and with their old semantics) * One release is made with the deprecated; the next release afterwards may remove all deprecated APIs I've switched to this policy for my 'newhttp' branch. You'll note that I have added an 'api' classvar to the transports. The client code alters its invocations based on that API. Also note that the transport APIs are *not* documented, so I have taken the position of "okay to change". Third parties who *write* their own transport class and pass to the "documented" transport_class argument of RiakClient/RiakSearch may need to change their code. If their transport inherits from RiakHttpTransport or RiakPbcTransport, then it will "suddenly" jump from api==1 to api==2. If they wrote their transport from scratch (and/or subclassing RiakTransport), then it will remain as api==1 and function as before. I don't have a better solution (without applying further thought), but am going to say "good enough" with the position that RiakTransport and its subclasses are not documented and (thus) subject to change. Applications that simply pass a builtin transport will require no change. For all those getters/setters, we can mark them as deprecated (using [1]) and then simply add the new properties. Cheers, -g [1] https://github.com/gstein/riak-python-client/commit/85e9d5460787d2ad6b66663e07b106f8cd71e05d _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
