feature suggestion: supporting attribute calls with argument given in map about libpython-clj HOT 7 CLOSED

@davidpham87 sorry for delayed response.

How would you feel about this:

(py. obj **method arg1 arg2 arg3 ... argN kwargs) where last argument is interpreted as a map?

That same modification would then percolate to

(py.. obj (**method1 arg1 arg2 ... kwargs) (**method2 arg1 arg2 ... kwargs))

or would you prefer

(py. obj **method args kwargs)?

I could probably also do (py. obj method *args **kwargs) pretty easily with a little macro magic but I'd like to hear how @cnuernber feels about that.

from libpython-clj.

The last option would be the most flexible.

(py. obj method *args) would be equivalent to (py. obj method arg1 arg2 arg3 ... argN) and this could be mixed/matched with
(py. obj method **kwargs) which would be equivalent to (py. obj method :attr1 val1 :att2 :val2 ... :attrN :valN)

from libpython-clj.

@jjtolton No problem, you have been helping me on Zulip (I am Neo). I don't know which dark magic you use in macro world, but this would be great

(py. obj method **kwargs}) ;; or (py. module fn **{:as kwargs})

but I think

(py.** obj method kwargs)  ;;  

would be the cleanest of all. It could be just a function wrapping py/call-attr-kw.

But it would be great with module/function calls like

(np/linspace **{:start 0 :stop 1})

Let's wait on @cnuernber for his opinion.

from libpython-clj.

Alright after thinking it over, (py. obj method *args **kwargs) LITERAL syntax has a few problems. For instance, *args and **kwargs are both valid symbol names, so then I'd need to provide an escape character -- and now things are already getting pretty messy and a bit contraventional to Clojure idioms.

I'll investigate a (py.** method kwargs) macro and corresponding (py.. obj (**method kwargs)) form.

from libpython-clj.

@davidpham87 please review #57 and let me know if that looks like it will work the way you were expecting :)

from libpython-clj.

Thanks a lot for the work. I really love the syntax. I think though we should not support the multiarities of theses methods as it is counterintuitive. Maybe have an alias for py/call-kw to have the two arities.

The reason it bothers me is the **method variant as change the position of the kwargs (I know it is common in Clojure, but for a specialized library, what do you think of going with the “least amount of surprise” path?

from libpython-clj.

The kwargs is always last in **, which means if you use it with just one arg, that arg will be the kwargs, which would cover your original use-case. I figure that is the arrity that will probably be used most, but now there is an arrity that covers all options. But I’ll ask for some more feedback and see what the consensus is

from libpython-clj.