+1 on removing plus an explicit NOTE thread, to prevent any neglection due to the current title (deprecation).
Best Regards, Yu On Fri, 14 Jun 2019 at 18:09, Stephan Ewen <se...@apache.org> wrote: > Okay, so we seem to have consensus for at least deprecating them, with a > suggestion to even directly remove them. > > A previous survey also brought no users of that python API to light [1] > I am inclined to go with removing. > Typically, deprecation is the way to go, but we could make an exception > and expedite things here. > > [1] > https://lists.apache.org/thread.html/348366080d6b87bf390efb98e5bf268620ab04a0451f8459e2f466cd@%3Cdev.flink.apache.org%3E > > > On Wed, Jun 12, 2019 at 2:37 PM Chesnay Schepler <ches...@apache.org> > wrote: > >> I would just remove them. As you said, there are very limited as to what >> features they support, and haven't been under active development for >> several releases. >> >> Existing users (if there even are any) could continue to use older >> version against newer releases. It's is slightly more involved than for >> say, flink-ml, as you also have to copy the start-scripts (or figure out >> how to use the jars yourself), but it is still feasible and can be >> documented in the release notes. >> >> On 11/06/2019 15:30, Stephan Ewen wrote: >> > Hi all! >> > >> > I would suggest to deprecating the existing python APIs for DataSet and >> > DataStream API with the 1.9 release. >> > >> > Background is that there is a new Python API under development. >> > The new Python API is initially against the Table API. Flink 1.9 will >> > support Table API programs without UDFs, 1.10 is planned to support >> UDFs. >> > Future versions would support also the DataStream API. >> > >> > In the long term, Flink should have one Python API for DataStream and >> Table >> > APIs. We should not maintain multiple different implementations and >> confuse >> > users that way. >> > Given that the existing Python APIs are a bit limited and not under >> active >> > development, I would suggest to deprecate them in favor of the new API. >> > >> > Best, >> > Stephan >> > >> >>
