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

Order enforcing wrapper fix #1205

Merged

Conversation

dm-ackerman
Copy link
Contributor

@dm-ackerman dm-ackerman commented May 6, 2024

Description

Fix several issues related to OrderEnforcingWrapper

Fixes #1174

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Checklist:

  • I have run the pre-commit checks with pre-commit run --all-files (see CONTRIBUTING.md instructions to set it up)
  • I have run pytest -v and no errors are present.
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I solved any possible warnings that pytest -v has generated that are related to my code to the best of my knowledge.
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

The following were removed:

value == "unwrapped" - will never be triggered because the base class has an unwrapped property which returns the same result

value == "render_mode" - duplicates the effect of the base class's __getattr__.

value == "possible_agents", "observation_spaces", "action_spaces", and "agent_order" - not related to the stated goal of the class
The previous one did not accurately reflect the class behavior.
The problem stemmed from the iterator being based on AECEnv
but accessing env._has_updated which only exists in the
OrderEnforcingWrapper.

Pyright's error is correct based on the types given in the code.
However, the usage of the class is correct. This is a workaround
that uses a more precise type and convinces pyright that the code
is correct.
@@ -61,20 +61,6 @@ def warn_action_out_of_bound(
f"[WARNING]: Received an action {action} that was outside action space {action_space}. Environment is {backup_policy}"
)

@staticmethod
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why exactly was this stuff removed? Looks kind of messy code and isn’t done in the other wrappers so can probably see it just want to make sure it’s on purpose that it got removed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is dead code that is never called. I think it was maybe intended to be used in the OrderEnfocingWrapper - and maybe was used in an older version of it, but it's not used anymore. The code is specific to that wrapper, if it's not used there, there's no other place it would be useful.

# strictly true, but it should have OrderEnforcingWrapper somewhere
# in the wrapper list). This might be better handled by Protocols,
# but this approach works.
self.env = env # silence pyright errors
Copy link
Collaborator

Choose a reason for hiding this comment

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

Imo we’re better off just ignoring the pyright error directly vs setting a variable too early or having extra variables that aren’t set exactly how they should be, simpler that way

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fair enough. I changed this back.

assert (
self.env._has_updated # pyright: ignore[reportGeneralTypeIssues]
self.env._has_updated
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we can just do ignore general type issues at the top of the file instead of these ugly in line ones (assuming that’s the main reason you changed this)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I re-added this per above comment. I think the end of line one is better in this case, even though it is ugly. Ignoring any error that might show up in the file isn't great. This is a generic catch-all error too, so it has a bigger chance of hiding something important that we don't know about.

Copy link
Collaborator

@elliottower elliottower left a comment

Choose a reason for hiding this comment

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

Have a few qualms and don’t fully remember the issue but code looks fine to me upon first glance. Maybe it should be tested though that this previous error doesn’t happen? And hopefully put it in the same place that the other wrappers are tested

@dm-ackerman
Copy link
Contributor Author

Have a few qualms and don’t fully remember the issue but code looks fine to me upon first glance. Maybe it should be tested though that this previous error doesn’t happen? And hopefully put it in the same place that the other wrappers are tested

The issue was mainly that the wrapper wasn't doing what it said it was and was doing things that didn't relate to enforcing order. I think this was all left over from other changes that were made previously. There isn't really an error from that issue that can be tested, it was mostly noticing that the details didn't match the docs.

@jjshoots jjshoots merged commit 1282a0a into Farama-Foundation:master Jun 21, 2024
46 checks passed
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.

[Bug Report] Incorrect behaviour from __getattr__ in OrderEnforcingWrapper?
3 participants