Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add explicit scopes to CSE #150

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

alexfikl
Copy link
Collaborator

@alexfikl alexfikl commented Oct 1, 2024

There are quite a few deprecation warnings from that, so this adds the explicit scopes in mappers and others things.

I didn't add it in make_common_subexpression. Should that also defaults to EVALUATION now? As a "helper" function, I would sort of expect it to do the right thing™ (?).

Copy link
Owner

@inducer inducer left a comment

Choose a reason for hiding this comment

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

Thx!

pymbolic/mapper/c_code.py Outdated Show resolved Hide resolved
Comment on lines 902 to 903
warn("Attribute 'init_arg_names' of {cls} is deprecated and will "
"be removed in 2025. Use dataclasses.fields instead.",
Copy link
Owner

Choose a reason for hiding this comment

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

The phrasing here is a bit odd, since it claims we'll magically remove these attributes in 2025. Reword?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Comment on lines 916 to 917
warn("Method '__getinitargs__' of {cls} is deprecated and will "
"be removed in 2025. Use dataclasses.fields instead.",
Copy link
Owner

Choose a reason for hiding this comment

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

The phrasing here is a bit odd, since it claims we'll magically remove these attributes in 2025. Reword?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

pymbolic/primitives.py Outdated Show resolved Hide resolved
@@ -1796,13 +1796,13 @@ def wrap_in_cse(expr, prefix=None):
if prefix is None:
return expr
if expr.prefix is None and type(expr) is CommonSubexpression:
Copy link
Owner

Choose a reason for hiding this comment

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

Use same logic as make_cse below.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hm, I'm not sure what you had in mind here? At least at a first glance, these seem to have different logic: make_cse ignores the prefix when re-wrapping and wrap_in_cse ignores the scope when re-wrapping.

test/test_pymbolic.py Outdated Show resolved Hide resolved
Comment on lines 54 to +55
Notice that if we were to directly generate code from this, the
subexpression *u* would be evaluated multiple times.
subexpression *u* would not be evaluated multiple times.
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

? Is this right?


def make_common_subexpression(expr: ExpressionT,
prefix: str | None = None,
scope: str | None = None) -> ExpressionT:
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Left scope=None here because setting it to scope=cse_scope.EVALUATION shows the actual string in the docs (i.e. "pymbolic_eval"), which are not shown in the docs for cse_scope itself.. very confusing :\

Comment on lines -927 to +997
cls.__eq__ = {cls.__name__}_eq
if {hash}:
cls.__eq__ = {cls.__name__}_eq
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This also guards the __eq__ override with hash. Was playing with IntG and it also needs to overwrite equality (seems mostly used in tests?).

Not sure if it's worth adding a separate eq flag (to match dataclass)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Would these better default to "__eq__" in cls.__dict__? It seems like the dataclass decorator also does similar checks to not overwrite the user implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants