Skip to content

Remove faulty override of reset method in JoypadSpace wrapper#93

Closed
acjh wants to merge 1 commit into
Kautenja:masterfrom
acjh:patch-1
Closed

Remove faulty override of reset method in JoypadSpace wrapper#93
acjh wants to merge 1 commit into
Kautenja:masterfrom
acjh:patch-1

Conversation

@acjh
Copy link
Copy Markdown

@acjh acjh commented Jun 27, 2023

Description

Fixes https://stackoverflow.com/questions/76509663/typeerror-joypadspace-reset-got-an-unexpected-keyword-argument-seed.

JoypadSpace doesn't correctly override the reset() method of Wrapper.

  • JoypadSpace reset() was implemented for gym 0.10.5 in nes-py 0.8.7 (Jul 2018).
  • Wrapper reset() was defined with **kwargs in gym 0.10.6 (Oct 2018).
    Though at the time Env reset() did not accept any parameters.
  • Env reset() started to accept seed parameter in gym 0.22.0 (Feb 2022).

Since nes-py now requires gym>=0.17.2, it is unnecessary to implement (override) reset() method.

Type of change

Please select all relevant options:

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Since nes-py now requires gym>=0.17.2, removing the method override is a non-breaking change.

How Has This Been Tested?

Not tested yet (I'm not a nes-py user), but the fix is straightforward.

Test Configuration

NIL.

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • [N.A.] I have commented my code, particularly in hard-to-understand areas
  • [N.A.] I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works

@ItaiBear ItaiBear mentioned this pull request Jul 17, 2023
10 tasks
@Kautenja
Copy link
Copy Markdown
Owner

Thanks for the focused fix here. PR #106 includes the same JoypadSpace.reset(...) compatibility work as part of the broader Gymnasium migration, with tests around seed/options forwarding and wrapper behavior. I’m closing this in favor of #106 so the project can land the full API update through one maintained merge path, but the issue you called out is definitely addressed there.

@Kautenja Kautenja closed this May 17, 2026
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