"not iterable" TypeError due to exp_manager.py's is_atari()/is_bullet()/is_robotics_env() assuming entry_point of type str
See original GitHub issueDescribe the bug
In OpenAI Gym’s register
function, the keyword argument entry_point
accepts a value of type str
as well as a gym.Env
subclass.
If a custom environment has been registered using the latter option (as a class), exp_manager.py
produces a TypeError: 'type' object is not iterable
when trying to check whether the string "AtariEnv"
is contained in gym.envs.registry.env_specs[env_id].entry_point
.
Code example
# myexample.py
# ...assuming that some gym env class MyExample exists...
from gym.envs.registration import register
register(
id="MyExample-v0",
entry_point=MyExample,
)
# utils/import_envs.py
import myexample
(as recommended here)
> python train.py --env MyExample-v0
========== MyExample-v0 ==========
Seed: 1193172183
EnvSpec(MyExample-v0)
Traceback (most recent call last):
File "train.py", line 181, in <module>
no_optim_plots=args.no_optim_plots,
File "/Users/asschude/Documents/PhD/code/rl-baselines3-zoo/utils/exp_manager.py", line 116, in __init__
self._is_atari = self.is_atari(env_id)
File "/Users/asschude/Documents/PhD/code/rl-baselines3-zoo/utils/exp_manager.py", line 426, in is_atari
return "AtariEnv" in gym.envs.registry.env_specs[env_id].entry_point
TypeError: argument of type 'type' is not iterable
To restore full compatibility with gym’s register
, I suggest simply changing the check to "AtariEnv" in str(...)
, which will be using the class __str__
/__repr__
representation. Same for the other two checks.
I came across this when implementing a custom environment.
System Info Describe the characteristic of your environment:
- cloned SB3 from GitHub (https://github.com/DLR-RM/rl-baselines3-zoo/commit/4f97b7348ccddf387462de8c14d39b1e49bf9d99)
- Python 3.7.7
- torch==1.9.0
- gym==0.18.3
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Hi there!
Convenience while trying some one-off things, mainly.
I agree that packaging your stuff is a good practice, and I prefer to do it myself (just not for one-off tryouts). But in my experience, many researchers and practitioners I’ve dealt with so far have not been all too familiar with creating Python packages themselves. I’m not sure whether it would be a good message to env-creating newbies to set the bar higher than strictly necessary.
Although I have an opinion on whether you should use strings in code to refer to packages (IMO you should not for various reasons), this is not why I’m reporting this as a problem. The reason I’m suggesting to fix/change this is to keep things consistently in line with OpenAI Gym (and Baselines3 themselves, where I also see type hints like Union[str, Type[gym.Env]]), so that when other weirdos like myself try this, they won’t get cryptic errors. 😉
If a pull request like suggested before is welcome, I’d be glad to contribute it. 😃 An alternative would be to explicitly deprecate the use of strings with a message/exception so that people are informed more clearly about what’s going on.
BTW the issues I was facing have all been home-grown. 😉
Hi and thanks for your answer. I’m facing some unexpected challenges getting my env to work with baselines3-zoo, so I’m waiting with the PR for now to make sure those aren’t related to this issue. Will report back.