Lint found in ListPlot-point checking branch

[rocky]

The good stuff from #1245, but alas the thing we were trying to do there can cause an infinite loop in the eval_ListPlot routine. So let's do this part and narrow that PR.

[mmatera]

good catch!

[mmatera]

I do not get this: what is the purpose of this for?

[rocky]

In the follow-on, there may be elements coming from LisetExpression which are tuples. I had considered Iterable here, but list/tuple is a little more specific. The other change here is to use _ instead of plot_group because _ is just needed as a placeholder for the double iteration.

[rocky]

Oh, and Merry Christmas!

[mmatera]

And happy Hanukkah!

What I meant is that I do not understand the loop (neither the original):

        if all(
            isinstance(point, list) and len(point) == 2
            for plot_group in plot_groups
            for point in plot_groups
        ):

here, the loop for plot_group in plot_groups runs over a variable that is never tested or used.
If we remove this line, nothing change, won't it?

[rocky]

Here is my understanding of what this code does: if at the top level we have a list, then all of the list elements of the top-level list should also be lists. If that's not the case, then we'll return None and not try perform/evaluate ListPlot.

I've always found it flaky the way WMA works where if something is wrong, sometimes a message is not produced but, instead, nothing is done, and possibly a rewrite rule may down the line deal with the unchanged result.

So this kind of thing may be happening here. I assume this models WMA behavior.

[mmatera]

Here is my understanding of what this code does: if at the top level we have a list, then all of the list elements of the top-level list should also be lists. If that's not the case, then we'll return None and not try perform/evaluate ListPlot.

Ok, but the line with the loop over the underscore variable does not play any role on that.

I've always found it flaky the way WMA works where if something is wrong, sometimes a message is not produced but, instead, nothing is done, and possibly a rewrite rule may down the line deal with the unchanged result.

So this kind of thing may be happening here. I assume this models WMA behavior.

Yep, the general philosophy in WL seems to be that if there is a way in which an expression have a meaning, then the expression is acceptable. Otherwise, just leave it as it is, until a definition is provided.

[rocky]

Ok, but the line with the loop over the underscore variable does not play any role on that.

Ah. Good catch. I've removed that line and tested locally. I guess we should see if this has any effect on anything, so I removed it in 84ddcb2.

There is a lot of code that still stinks. mypy flags some fishy things like the fact that we were looping over a variable that isn't used. But I guess it is up to us to understand whether the entire double loop is even necessary. And here, there is still too much code that feels screwy that my mind glosses over some of the remaining mess that is still there. So in sum, thanks.

.

[mmatera]

The plot module contains a large and entangled code, which have passed through a couple of refactors, so this kind of things are expactable. Hopefully, as we continue disentangling this, we will eventually to converge to something more clear and solid.

[rocky]

In particular, I was trying to get Mesh with an integer value working. I see that while for Plot we have moved this code over to eval, for Plot3D, we haven't.

I gave up on getting Mesh working with an integer value.

[rocky]

Ok. We are passing now. Merging before something else breaks. Feel free to follow up with any of the numerous messes that remain.