Thanks, what's the error message in this case? Does it clarify the non-Constant issue?

My understanding is that padding arg in reflecion_pad and replication_pad ops is always an array of ints.
Could padding be a single int?
Also, can you use _maybe_get_const() function from symbolic_helper to parse 'is'?
If the output is still a torch._C.Value, then throw the exception?

You are correct. The padding arg has to be an array of ints, which can be represented either in an onnx::Constant node containing a tensor value, or a prim::ListConstruct node.

In reply to: 441648471 [](ancestors = 441648471)

Sorry I meant sym_helper._get_const here.
Maybe something like:

    try:
        padding = sym_help._get_const(padding, 'is', 'constant_pad_nd')
    except:
        _unimplemented('constant_pad_nd', "<msg>")

can you simplify the code by using _unpack_list: https://github.com/pytorch/pytorch/blob/master/torch/onnx/symbolic_helper.py#L109
to get the list values from prim::ListConstruct?

Sorry I should've asked for sym_help._get_const here.
This one throws an error if all list elements are not const.
Maybe something like:

 try:
        padding = sym_help._get_const(padding, 'is', 'constant_pad_nd')
    except:
        _unimplemented('constant_pad_nd', "<msg>")

I think sym_help._get_const won't work in this case, because this is the condition that it checks (it throws an exception when it is true):

_is_value(value) and value.node().kind() not in ('onnx::Constant', 'prim::Constant')

and in the padding case, it can also be prim::ListConstruct.

But I did use your suggestion below for parsing the value in constant_pad_nd.

In reply to: 443761593 [](ancestors = 443761593)

How about after you unpack the list? Maybe like:

try:
    padding = [sym_help._get_const(v, 'is', 'constant_pad_nd') for v in input_list]
except:
    _unimplemented('constant_pad_nd', "<msg>")

It checks for prim:Constant type as well, also use of _unimplemented is more consistent.
I'm trying to avoid custom arg parsing or error handling for symbolics.

This looks okay for now. If see this type of error handling (per opset) repeating more often, we should handle it in a separate function to make it more generic.