One thing that slightly worries me about this is that comparingstr/int andbytes objects raisesUnicodeWarning if the-b option was passed on the command line. With this change, additional checks are required if we want to makeCOMPARE_OP able to constant-evaluate in the optimizer.

One thing that slightly worries me about this is that comparingstr/int andbytes objects raisesUnicodeWarning if the-b option was passed on the command line. With this change, additional checks are required if we want to makeCOMPARE_OP able to constant-evaluate in the optimizer.

Ok let's not do this then. We still need to fix the long stuff though so@sobolevn are you open to that or do you want me to handle it?

I opened PR#136040 to fix the compact ints issue.

With this change, additional checks are required if we want to make COMPARE_OP able to constant-evaluate in the optimizer.

Did you mean checking for_Py_GetConfig()->bytes_warning conditionally? I fear that this might be really slow :(

With this change, additional checks are required if we want to make COMPARE_OP able to constant-evaluate in the optimizer.

Did you mean checking for_Py_GetConfig()->bytes_warning conditionally? I fear that this might be really slow :(

You can fetch the value once at the start of optimization time inoptimizer_analysis.c, and store it somewhere.

Or, simpler, just explicitly disallow optimizing the problematic comparisons.

If one of the values is of type bytes, require the other to be as well.

Or, simpler, just explicitly disallow optimizing the problematic comparisons.

Not just comparisons. BINARY_OP as well. This is a little annoying and more involved than I expected, so I'd say let's just ignore it for now?

WhatBINARY_OP will raiseBytesWarning?

WhatBINARY_OP will raiseBytesWarning?

Not BytesWarning. BINARY_OP (str, bytes) will throw.

That’s the case for many combinations of safe types. We should suppress the error and hit bottom in that case (in theerror label).

Same for42 / 0, etc. In general, errors in the optimizer should just be suppressed.

This is just different because it’s a warning, to clarify.

That’s the case for many combinations of safe types. We should suppress the error and hit bottom in that case (in theerror label).

Yeah the optimizer currently doesn't do that. Opened a PR to do so#136048

I openedhttps://discuss.python.org/t/consider-deprecating-and-eventually-removing-b-cli-flag/96903 about possibly removing this warning in the future versions. It does not seem very useful :(

I fixed the merge conflict. Sorry, I am rather new to the JIT internals, and I don't quite understand theCOMPARE_OP part._Py_uop_sym_is_safe_const is never called forCOMPARE_OP. So, I don't know how to interpret these comments :)

With this change, additional checks are required if we want to make COMPARE_OP able to constant-evaluate in the optimizer.

Or, simpler, just explicitly disallow optimizing the problematic comparisons.

Is there anything I need to do in this PR to address them?

I fixed the merge conflict. Sorry, I am rather new to the JIT internals, and I don't quite understand theCOMPARE_OP part._Py_uop_sym_is_safe_const is never called forCOMPARE_OP. So, I don't know how to interpret these comments :)

We plan to follow up shortly with COMPARE_OP here#130415

Ok then :)
Let's close it for now.