"not iterable" TypeError due to exp_manager.py's is_atari()/is_bullet()/is_robotics_env() assuming entry_point of type str

Describe 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

[schuderer]

Hi there!

I didn’t know that… but why would you use something different that what all other gym env uses?

Convenience while trying some one-off things, mainly.

Having it as a string forces you to properly specify the path and have everything as a python package which is good practice.

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. 😉

[schuderer]

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.