zlacker

[parent] [thread] 4 comments
1. saiojd+(OP)[view] [source] 2023-05-20 00:43:59
Another thing that TS does nicely is object handling in general: dot access for objects attributes, object destructuring, typed objects for function options. In most ML projects I see a bunch of functions that look like:

    def my_fn(x, **kwargs):
       ...
       return y_1, y_2, y_3
Which is a pain because kwargs could be anything really + now every call site has to expect 3 return values exactly while knowing their order; there's no way of adding an extra return value without changing everyone. In typescript the same function could look like:

    function myFn(x, options = { someOption: 1 }) {
       ...
       return { y_1, y_2, y_3 };
    }
Which is so much nicer because everything is typed with all types inferred automatically! And you don't burden the call sites with values they don't need:

    const { y_1 } = myFn(x, { someOption: 1 });
In Python, everyone mostly passes unbundled arguments through every function, and changing anything involves threading these untyped arguments through a bunch of untyped call sites, its not the end of the world but we can do better...
replies(2): >>praecl+s4 >>int_19+zWa
2. praecl+s4[view] [source] 2023-05-20 01:37:16
>>saiojd+(OP)
I’m of the same opinion. While I think I will keep the standard parameter order from torch, I will include the options overload to give all the benefits you describe.
replies(1): >>saiojd+Y7
◧◩
3. saiojd+Y7[view] [source] [discussion] 2023-05-20 02:25:47
>>praecl+s4
Awesome :D Really nice project by the way
4. int_19+zWa[view] [source] 2023-05-23 20:29:05
>>saiojd+(OP)
Python also has pattern matching on dicts and typed kwargs these days. It seems that the only thing missing is syntactic sugar for unconditional destructuring.
replies(1): >>saiojd+khj
◧◩
5. saiojd+khj[view] [source] [discussion] 2023-05-26 10:53:02
>>int_19+zWa
Yes! It's getting close, but we are still far from things being convenient and widely adopted
[go to top]