There was a brief discussion on a JIRA about following the pattern like: Main task: API change proposal - subtask: Java change - subtask: Python change - subtask: ... etc ...
This allows asynchrony without losing track of our intent. Of course, I hope Beam is so successful that we have too many SDKs to keep them in sync :-) Aside from that, there are some of us who are as fluent in Python as in Java, but we shouldn't expect that to be universal. And we should always consider opinions of SDK authors as to what is most idiomatic for their language and SDK. Kenn On Sun, May 21, 2017 at 11:45 AM, Dan Halperin <[email protected]> wrote: > I think this is an unrealistic request -- Python and Java workflows are > completely different, and Python developer documentation is especially > abysmal. > > (E.g., I had to have Robert sit with me to get the Python SDK to work at > all on my developer machine, and even then I gave up and chmod-ed my > machine-wide Python repos to be world-writable to get it to work.) > > On Fri, May 19, 2017 at 4:50 PM, Ahmet Altay <[email protected]> > wrote: > > > I mentioned this in the PR, I believe it is worth repeating here. > > > > It is important to keep the API consistent between Python and Java. It > > would help a lot, if changes are applied to both SDKs at the same time. > If > > that is not possible, an easier alternative would be to file a JIRA issue > > so that the work could be tracked in the other SDK. > > > > Ahmet > > > > On Fri, May 19, 2017 at 4:22 PM, Robert Bradshaw < > > [email protected]> wrote: > > > > > I see this was implemented. Do we have a policy/guideline for when a > > > name is "bad enough" to merit renaming (and keeping a duplicate, > > > deprecated member around for a year or more). > > > > > > On Mon, May 15, 2017 at 9:25 AM, Robert Bradshaw <[email protected]> > > > wrote: > > > > On Sun, May 14, 2017 at 3:36 PM, Ben Chambers > > > <[email protected]> > > > > wrote: > > > >> > > > >> Exposing the CombineFn is necessary for use with composed combine or > > > >> combining value state. There may be other reasons we made this > > visible, > > > >> but > > > >> these continue to justify it. > > > > > > > > > > > > These are the CompareFns, not the CombineFns. > > > > > > > > It'd be nicer to use the Guava and/or Java8 natural ordering > > comparables, > > > > but they don't promise serializable. > > > > > > > > I agree the naming is unfortunate, but I don't know that it's bad > > enough > > > to > > > > introduce a new name and have duplication and deprecation in the API. > > It > > > > also goes deeper than this; Top.of(...) gives elements in > *decreasing* > > > order > > > > while List.sort(...) gives elements in *increasing* order so using a > > > > comparator in one will always produce the opposite effect of using a > > > > comparator in the other. > > > > > > > >> > > > >> On Sun, May 14, 2017, 1:00 PM Reuven Lax <[email protected]> > > > wrote: > > > >> > > > >> > I believe the reason why this is called Top.largest, is that > > > originally > > > >> > it > > > >> > was simply the comparator used by Top.largest - i.e. and > > > implementation > > > >> > detail. At some point it was made public and used by other > > transforms > > > - > > > >> > maybe making an implementation detail a public class was the real > > > >> > mistake? > > > >> > > > > >> > On Sun, May 14, 2017 at 11:45 AM, Davor Bonaci <[email protected]> > > > wrote: > > > >> > > > > >> > > I agree this is an unfortunate name. > > > >> > > > > > >> > > Tangential: can we rename APIs now that the first stable release > > is > > > >> > nearly > > > >> > > done? > > > >> > > Of course -- the "rename" can be done by introducing a new API, > > and > > > >> > > deprecating, but not removing, the old one. Then, once we decide > > to > > > >> > > move > > > >> > to > > > >> > > the next major release, the deprecated API can be removed. > > > >> > > > > > >> > > I think we should probably do the "rename" at some point, but > I'd > > > >> > > leave > > > >> > the > > > >> > > final call to the wider consensus. > > > >> > > > > > >> > > On Sat, May 13, 2017 at 5:16 PM, Wesley Tanaka > > > >> > > <[email protected] > > > >> > > > > > >> > > wrote: > > > >> > > > > > >> > > > Using Top.Largest to sort a list of {2,1,3} produces {1,2,3}. > > > This > > > >> > > > matches the javadoc for the class, but seems counter-intuitive > > -- > > > >> > > > one > > > >> > > might > > > >> > > > expect that a Comparator called Largest would give largest > items > > > >> > > > first. > > > >> > > > I'm wondering if renaming the classes to Natural / Reversed > > would > > > >> > better > > > >> > > > match their behavior? > > > >> > > > > > > >> > > > --- > > > >> > > > Wesley Tanaka > > > >> > > > https://wtanaka.com/ > > > >> > > > > > >> > > > > > > > > > > > > > > >
