To extend number of possible types from another module need to do:

// shadow_somemodule.hpp
struct GCompileArg {
    GAPI_WRAP GCompileArg(module::SomeArg arg);
};

This code adds new overload to GCompileArg ctor

But how did you solve variadic arguments passing?

it's solved indirectly through python's compile_args (which probably requires a better PR name since it's confusing - vaargs is a thing in C++ as well).

map() calls a function for each element of a range. given that the function is a GCompileArg ctor, we convert "raw" args into a range containing cv2.GCompileArg(arg) elements (by the way, does ctor qualify as a function?)

by the way, does ctor qualify as a function

Why not ? https://stackoverflow.com/questions/11943831/python-how-to-put-constructors-in-map-function

it's solved indirectly through python's compile_args (which probably requires a better PR name since it's confusing - vaargs is a thing in C++ as well).

map() calls a function for each element of a range. given that the function is a GCompileArg ctor, we convert "raw" args into a range containing cv2.GCompileArg(arg) elements (by the way, does ctor qualify as a function?)

while I like the idea, this API is not quite equivalent. what if, as a user, I have my own gapi::GMyOwnPackage - how can I use compile_args machinery to wrap this external-to-G-API package?
it seems remotely possible with the old API (just add a new overload of compile_args) - albeit, I'm not sure if python has anything like function overload resolution/adl (wondering how this old API works) - if this is out of scope for this (e.g. G-API only supports packages that it provides itself via compile_args and users have to do something else), then feel free to ignore this.

Wow, glad to see u :)

As for gapi::GMyOwnPackage what do u mean ? Do u want to use your own compile argument ?
From python user can't define new compile argument.

Wow, glad to see u :)

Just occasionally looking at things here, nothing too serious 😉

As for gapi::GMyOwnPackage what do u mean ? Do u want to use your own compile argument ?

Yes, imagine such a use case (maybe someone wants their own package - it is the thing that provides the kernels/etc, right? can't remember anymore).

From python user can't define new compile argument.

Well, it should be doable from C++ and then C++ gets magically converted into python - I guess, ideally, G-API should be convenient to use from python as well, so if someone supplies their own package, it could be used from python API as well.
However, this is a purely artificial use case. I wrote this comment in the meaning of:
you change the API and this (might) limit the usability - e.g. the ability to use custom packages in python. if this was never a concern, then this change is perfectly fine.

(glad to see you as well!)

Yes, imagine such a use case (maybe someone wants their own package - it is the thing that provides the kernels/etc, right? can't remember anymore).

Again, what's the purpose of the gapi::GMyOwnPackage ? First of all it won't be recognized inside G-API, right ? Secondly if the user want to pass his own set of kernels it can be easily done by using cv.gapi.kernels(....) which returns gapi::GKernelPackage

I mean that user defined compile arguments are useless because there is no support inside G-API to handle them.

ah, I get it now. no objections then.

;

Done

cv2 => cv2.gapi ?

(as there is no "G" prefix)

but in c++ it's a part of cv namespace, not cv::gapi

It will be a bit weird to keep it in cv.gapi package in that case. Are u Ok to leave it as is ?

@dmatveev Please confirm this usage.

@alalek yes somehow we have cv::compile_args but not cv::gapi::compile_args in our C++ API.

It is definitely worth aligning in 5.0

Then it makes sense to keep it in cv.gapi for python.

Done