Skip to content

Conversation

xadupre
Copy link
Member

@xadupre xadupre commented Oct 6, 2025

No description provided.

Copy link

codecov bot commented Oct 6, 2025

Codecov Report

❌ Patch coverage is 74.62687% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.96%. Comparing base (6718ef0) to head (86d482d).

Files with missing lines Patch % Lines
onnxscript/function_libs/torch_lib/ops/core.py 74.62% 9 Missing and 8 partials ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2606   +/-   ##
=======================================
  Coverage   69.95%   69.96%           
=======================================
  Files         222      222           
  Lines       26311    26375   +64     
  Branches     2604     2617   +13     
=======================================
+ Hits        18406    18453   +47     
- Misses       6993     7002    +9     
- Partials      912      920    +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

<https://github.com/pytorch/pytorch/blob/main/torch/onnx/symbolic_opset11.py#L212>`_.
"""
if len(indices) > 1 and any(
isinstance(indice, torch.onnx._internal.exporter._tensors.SymbolicTensor)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check not isinstance(index, int) instead as we should not reference the private class.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the possible types here? Only int and SymbolicTensor? I prefer to keep SymbolicTensor because I know exactly which type the function is supposed to handle.

Copy link
Collaborator

@justinchuby justinchuby Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only int and SymbolicTensor for the exporter, but could be other ir.Value subclasses as well. As the type is an internal type it is not meant for public use, the current usage is not supported and is brittle.

If preferred you may check for ir.Value instead, but really we just assume a type that has shape and dtype fields

return op.ReduceProd(op.Shape(x, start=i + 1), keepdims=1)

shape = [1] * (len(x.shape) + 1)
mfixed = []
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer clear variable names and avoid abbreviations.

Copy link
Member Author

@xadupre xadupre Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The variable are used just after. It is short to make the code shorter and esier to read.

Copy link
Collaborator

@justinchuby justinchuby Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any abbreviation adds cognitive load and is not preferred. All names should be thoughtfully created to be precise. Creating variables used right after is a plus but I don’t feel warranting the use of ambiguous names.

https://google.github.io/styleguide/pyguide.html#316-naming

@xadupre xadupre marked this pull request as ready for review October 7, 2025 11:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

2 participants