Hey folks, Just wanted to give an update on this. With 1.1, the Python client will basically be at parity with the Java and C++ clients. There are a few minor things missing here and there, some of which i'm not sure really need exposed in Python anyways. The only missing piece that I'd like to eventually get in there is the async capabilities, however I dont think that will be all that pressing for python devs. Note that because it's now caught up, we'll be bumping the python client version to 1.1 (instead of 0.4) this release.
Next steps for 1.2: - Pydoc (top priority) - Pandas integration - Additional "pythonic" improvements - Keep pace with other changes, particularly new security features Let me know if you have any opinions or questions. Thanks, Jordan On Thu, Oct 6, 2016 at 12:16 PM Todd Lipcon <[email protected]> wrote: > On Tue, Sep 27, 2016 at 4:04 PM, Jordan Birdsell < > [email protected]> > wrote: > > > Hey folks, > > > > I know I've thrown around a few ideas lately regarding the python client > as > > well as started trying to bring it up to speed with the rest of the kudu > > world, so I thought i'd try and bring it all back together with a road > map > > of sorts and get you alls thoughts. > > > > For starters, I've had a change in heart for now about a complete > rebuild, > > unless anyone objects. I think we can get the desired pythonic feel > without > > really any breaking changes and if there are any, we can phase out the > old > > functionality. I'm now favoring this over a full rebuild since we'd have > to > > support old/new for a while anyways. > > > > > Yea, if there aren't breaking changes I think doing it incrementally is > probably the easier approach. > > Also, in the mean time, there is a lot of "catching up" to do to get on par > > with everything else. In this catch up phase, i'd like to propose that > we > > release outside of the ASF release schedule. Since the python package > isn't > > really tied to ASF releases this would help speed things up I think. > > > > > As an ASF project we can't do official releases without going through a > normal VOTE process. That said, we're permitted to release multiple > different artifacts from the same project -- i.e we can call a vote for > just a Python client release if we like. > > That said, there are some potential issues: the Python client wraps the C++ > one, and so if we were to release a new Python client today, it wouldn't > work with the older C++ client due to missing features (eg IN-list > predicate support). With enough effort this could be worked around, > probably (eg by adding #Ifdefs into the Python client to compile out things > that aren't present in your installed C++ one) but I don't know that it's > worth the effort. > > We generally have been doing releases once every 2-3 months, so my personal > preference is to just wait until the next project-wide release rather than > doing intermediary ones. > > -Todd > -- > Todd Lipcon > Software Engineer, Cloudera >
