+1 (binding) as I've already said :) -ash
> On 6 Dec 2019, at 00:55, Tao Feng <fengta...@gmail.com> wrote: > > -1 (binding) > > I share the same with most other comments. And I personally prefer to use > try,except to make it consistent across the code base while use assert in > unit test . > > On Thu, Dec 5, 2019 at 3:09 PM Felix Uellendall <felue...@pm.me.invalid> > wrote: > >> -1 (binding) >> >> I agree. There shouldn’t be any confusion around this if we want to >> introduce this. The old/current assertion style still looks more readable >> to me. >> >> Felix >> >> Sent from ProtonMail Mobile >> >> On Thu, Dec 5, 2019 at 23:35, Kevin Yang <yrql...@gmail.com> wrote: >> >>> -1 (binding). >>> >>> People in the old thread has spoken for me. Specifically in Python, the >>> confusion introduced by using asserts IMO can defeat all the benefits >>> mentioned easily. >>> >>> Kevin Y >>> >>> On Thu, Dec 5, 2019 at 8:27 AM Tomasz Urbaszek < >> tomasz.urbas...@polidea.com> >>> wrote: >>> >>>> -1 (non-binding) >>>> >>>> T. >>>> >>>> >>>> On Thu, Dec 5, 2019 at 4:16 PM Deng Xiaodong <xd.den...@gmail.com> >> wrote: >>>> >>>>> -1 (binding). >>>>> >>>>> As shared earlier, the benefit it brings may not be enough to break >> even >>>>> for me. And it’s not irreplaceable. >>>>> >>>>> >>>>> XD >>>>> >>>>>> On 5 Dec 2019, at 11:10 PM, Kaxil Naik <kaxiln...@gmail.com> wrote: >>>>>> >>>>>> -1 (binding) it definitely seems to be a source of confusion and >>>>> comparing >>>>>> it to the advantages it provides, I would be hesitant on using it. >>>>>> >>>>>> On Thu, Dec 5, 2019 at 2:56 PM Jarek Potiuk < >> jarek.pot...@polidea.com> >>>>>> wrote: >>>>>> >>>>>>> Here is a quick vote on using asserts in Airflow code. >>>>>>> >>>>>>> It is distilled from the discussion >>>>>>> https://lists.apache.org/list.html?dev@airflow.apache.org. >>>>>>> >>>>>>> Here are the two options: >>>>>>> >>>>>>> *[+1]* Allow using asserts in some specific cases.* >>>>>>> *[-1]**: Forbid using asserts.* >>>>>>> >>>>>>> The voting will last till Monday 4 pm CET. The committers have >> binding >>>>>>> votes, but everyone is encouraged to call advisory - non-binding - >>>>> votes as >>>>>>> well. >>>>>>> >>>>>>> Consider that my +1 (binding) vote. >>>>>>> >>>>>>> >>>>>>> * [+1] The case are clearly "strictly meant for developers" >> assertions >>>>>>> (None fields mainly) - which are more like type annotations and >> can be >>>>>>> stripped away when optimising. If those asserts are stripped out, >>>>> another >>>>>>> exception will be thrown out shortly. If we agree to that we will >> add >>>>> some >>>>>>> clear rules for those asserts in CONTRIBUTING.md and make it part >> of >>>>> code >>>>>>> review process to check if assertions are "proper". >>>>>>> >>>>>>> ** [-1] Forbidding using asserts is mainly due to ambiguities when >> to >>>>>>> use/when to not use asserts. If we agree to that, we will forbid >> using >>>>>>> asserts via pre-commits and remove all assertions in our code. >>>>>>> >>>>>>> J. >>>>>>> -- >>>>>>> >>>>>>> Jarek Potiuk >>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer >>>>>>> >>>>>>> M: +48 660 796 129 <+48660796129> >>>>>>> [image: Polidea] <https://www.polidea.com/> >>>>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Tomasz Urbaszek >>>> Polidea <https://www.polidea.com/> | Junior Software Engineer >>>> >>>> M: +48 505 628 493 <+48505628493> >>>> E: tomasz.urbas...@polidea.com <tomasz.urbasz...@polidea.com> >>>> >>>> Unique Tech >>>> Check out our projects! <https://www.polidea.com/our-work> >>>>
