passing on parameters and extra_category for cartesian products

[dkrenn]

When calling cartesian_product (functorial construction), keyword arguments should be passed on to the class constructor of CartesianProduct. This will allow to use classes inherited from sets.cartesian_product.CartesianProduct? to use these keywords as an input. Additionally it will be possible to add an extra category (to the determined one; instead of only specifying the exact category of the newly created cartesian product)

This ticket arises from #18223; existing code there is partially used here (since the solution there will not be used the usable parts was factored out)

[vdelecroix]

Hello,

Your change to sets_cat.py looks good to me. But what is the point of the ignored flatten argument and the forbidden kwargs in cartesian_product.py??

Vincent

[dkrenn]

Replying to vdelecroix:

But what is the point of the ignored flatten argument and the forbidden kwargs in cartesian_product.py??

It was already there before...I think the idea is that at some point in future, a cartesian product of cartesian products can be flattened, so that this results in a non-nested form of the cartesian product.

[vdelecroix]

Replying to dkrenn:

Replying to vdelecroix:

But what is the point of the ignored flatten argument and the forbidden kwargs in cartesian_product.py??

It was already there before...I think the idea is that at some point in future, a cartesian product of cartesian products can be flattened, so that this results in a non-nested form of the cartesian product.

Would it hurt to remove it? What about the kwargs that you added?

[dkrenn]

Replying to vdelecroix:

But what is the point of the ignored flatten argument and the forbidden kwargs in cartesian_product.py??

Would it hurt to remove it?

I wouldn't mind at all. I have not tested what happens if we do. ...but someone introduced it, maybe this person has an opinion on it?

What about the kwargs that you added?

They are not used in sets.cartesian_product.CartesianProduct but can be used in a derived class (e.g. #18223).

[vdelecroix]

Replying to dkrenn:

Replying to vdelecroix:

But what is the point of the ignored flatten argument and the forbidden kwargs in cartesian_product.py??

Would it hurt to remove it?

I wouldn't mind at all. I have not tested what happens if we do. ...but someone introduced it, maybe this person has an opinion on it?

He might. He is Nicolas Thiéry in commit c4629fde from 2010. But that is not the good way to go. We could add ignored parameters a, b, c, ... they might be very useful in the future.

What about the kwargs that you added?

They are not used in sets.cartesian_product.CartesianProduct but can be used in a derived class (e.g. #18223).

Why not adding it in #18223 then? With this ticket we end up with two arguments that are for future use. It is not an improvement.

[dkrenn]

Replying to vdelecroix:

They are not used in sets.cartesian_product.CartesianProduct but can be used in a derived class (e.g. #18223).

Why not adding it in #18223 then? With this ticket we end up with two arguments that are for future use. It is not an improvement.

The changes here in this ticket are the only changes that are needed in sets.cartesian_product.CartesianProduct. This here is general enough to be used in various derived classes; it does not have any relation to the content/topic of #18223. Thus separating it and making it its own ticket makes the changes clearer (so that not (silently) a new flag in the general class is introduced).

[dkrenn]

Replying to vdelecroix:

Why not adding it in #18223 then? With this ticket we end up with two arguments that are for future use. It is not an improvement.

Since no comments for a couple of weeks; I'll mark this ticket as "won't fix" and change the description of #18223 so that it will be clear that the changes here are included (since needed there).

Best

Daniel

[vdelecroix]

So let me not review it.