[Deprecation] Deprecate default num_cells in MLP (#2395)

docs/source/reference/collectors.rst

@@ -45,7 +45,7 @@ worker) may also impact the memory management. The key parameters to control are
 :obj:`devices` which controls the execution devices (ie the device of the policy)
 and :obj:`storing_device` which will control the device where the environment and
 data are stored during a rollout. A good heuristic is usually to use the same device
-for storage and compute, which is the default behaviour when only the `devices` argument
+for storage and compute, which is the default behavior when only the `devices` argument
 is being passed.
 
 Besides those compute parameters, users may choose to configure the following parameters:

docs/source/reference/data.rst

@@ -171,7 +171,7 @@ using the following components:
 Storage choice is very influential on replay buffer sampling latency, especially
 in distributed reinforcement learning settings with larger data volumes.
 :class:`~torchrl.data.replay_buffers.storages.LazyMemmapStorage` is highly
-advised in distributed settings with shared storage due to the lower serialisation
+advised in distributed settings with shared storage due to the lower serialization
 cost of MemoryMappedTensors as well as the ability to specify file storage locations
 for improved node failure recovery.
 The following mean sampling latency improvements over using :class:`~torchrl.data.replay_buffers.ListStorage`

docs/source/reference/envs.rst

@@ -318,7 +318,7 @@ have on an environment returning zeros after reset:
 
 We also offer the :class:`~.SerialEnv` class that enjoys the exact same API but is executed
 serially. This is mostly useful for testing purposes, when one wants to assess the
-behaviour of a :class:`~.ParallelEnv` without launching the subprocesses.
+behavior of a :class:`~.ParallelEnv` without launching the subprocesses.
 
 In addition to :class:`~.ParallelEnv`, which offers process-based parallelism, we also provide a way to create
 multithreaded environments with :obj:`~.MultiThreadedEnv`. This class uses `EnvPool <https://github.com/sail-sg/envpool>`_
@@ -499,7 +499,7 @@ current episode.
 To handle these cases, torchrl provides a :class:`~torchrl.envs.AutoResetTransform` that will copy the observations
 that result from the call to `step` to the next `reset` and skip the calls to `reset` during rollouts (in both
 :meth:`~torchrl.envs.EnvBase.rollout` and :class:`~torchrl.collectors.SyncDataCollector` iterations).
-This transform class also provides a fine-grained control over the behaviour to be adopted for the invalid observations,
+This transform class also provides a fine-grained control over the behavior to be adopted for the invalid observations,
 which can be masked with `"nan"` or any other values, or not masked at all.
 
 To tell torchrl that an environment is auto-resetting, it is sufficient to provide an ``auto_reset`` argument
@@ -755,10 +755,10 @@ registered buffers:
     >>> TransformedEnv(base_env, third_transform.clone())  # works
 
 On a single process or if the buffers are placed in shared memory, this will
-result in all the clone transforms to keep the same behaviour even if the
+result in all the clone transforms to keep the same behavior even if the
 buffers are changed in place (which is what will happen with the :class:`CatFrames`
 transform, for instance). In distributed settings, this may not hold and one
-should be careful about the expected behaviour of the cloned transforms in this
+should be careful about the expected behavior of the cloned transforms in this
 context.
 Finally, notice that indexing multiple transforms from a :class:`Compose` transform
 may also result in loss of parenthood for these transforms: the reason is that
@@ -1061,7 +1061,7 @@ the current gym backend or any of its modules:
 Another tool that comes in handy with gym and other external dependencies is
 the :class:`torchrl._utils.implement_for` class. Decorating a function
 with ``@implement_for`` will tell torchrl that, depending on the version
-indicated, a specific behaviour is to be expected. This allows us to easily
+indicated, a specific behavior is to be expected. This allows us to easily
 support multiple versions of gym without requiring any effort from the user side.
 For example, considering that our virtual environment has the v0.26.2 installed,
 the following function will return ``1`` when queried:

docs/source/reference/modules.rst

@@ -62,7 +62,7 @@ Exploration wrappers
 
 To efficiently explore the environment, TorchRL proposes a series of wrappers
 that will override the action sampled by the policy by a noisier version.
-Their behaviour is controlled by :func:`~torchrl.envs.utils.exploration_mode`:
+Their behavior is controlled by :func:`~torchrl.envs.utils.exploration_mode`:
 if the exploration is set to ``"random"``, the exploration is active. In all
 other cases, the action written in the tensordict is simply the network output.
 

examples/distributed/replay_buffers/distributed_replay_buffer.py

@@ -150,8 +150,8 @@ def _create_and_launch_data_collectors(self) -> None:
 
 class ReplayBufferNode(RemoteTensorDictReplayBuffer):
     """Experience replay buffer node that is capable of accepting remote connections. Being a `RemoteTensorDictReplayBuffer`
-    means all of it's public methods are remotely invokable using `torch.rpc`.
-    Using a LazyMemmapStorage is highly advised in distributed settings with shared storage due to the lower serialisation
+    means all of its public methods are remotely invokable using `torch.rpc`.
+    Using a LazyMemmapStorage is highly advised in distributed settings with shared storage due to the lower serialization
     cost of MemoryMappedTensors as well as the ability to specify file storage locations which can improve ability to recover from node failures.
 
     Args:

sota-implementations/redq/redq.py

@@ -159,7 +159,7 @@ def main(cfg: "DictConfig"):  # noqa: F821
         use_env_creator=False,
     )()
     if isinstance(create_env_fn, ParallelEnv):
-        raise NotImplementedError("This behaviour is deprecated")
+        raise NotImplementedError("This behavior is deprecated")
     elif isinstance(create_env_fn, EnvCreator):
         recorder.transform[1:].load_state_dict(
             get_norm_state_dict(create_env_fn()), strict=False

test/_utils_internal.py

@@ -56,7 +56,7 @@ def HALFCHEETAH_VERSIONED():
 
 def PONG_VERSIONED():
     # load gym
-    # Gymnasium says that the ale_py behaviour changes from 1.0
+    # Gymnasium says that the ale_py behavior changes from 1.0
     # but with python 3.12 it is already the case with 0.29.1
     try:
         import ale_py  # noqa
@@ -70,7 +70,7 @@ def PONG_VERSIONED():
 
 def BREAKOUT_VERSIONED():
     # load gym
-    # Gymnasium says that the ale_py behaviour changes from 1.0
+    # Gymnasium says that the ale_py behavior changes from 1.0
     # but with python 3.12 it is already the case with 0.29.1
     try:
         import ale_py  # noqa

test/test_cost.py

@@ -149,7 +149,12 @@
 
 
 # Capture all warnings
-pytestmark = pytest.mark.filterwarnings("error")
+pytestmark = [
+    pytest.mark.filterwarnings("error"),
+    pytest.mark.filterwarnings(
+        "ignore:The current behavior of MLP when not providing `num_cells` is that the number"
+    ),
+]
 
 
 class _check_td_steady:

test/test_libs.py

@@ -3682,7 +3682,7 @@ class TestRoboHive:
     # The other option would be not to use parametrize but that also
     # means less informative error trace stacks.
     # In the CI, robohive should not coexist with other libs so that's fine.
-    # Robohive logging behaviour can be controlled via ROBOHIVE_VERBOSITY=ALL/INFO/(WARN)/ERROR/ONCE/ALWAYS/SILENT
+    # Robohive logging behavior can be controlled via ROBOHIVE_VERBOSITY=ALL/INFO/(WARN)/ERROR/ONCE/ALWAYS/SILENT
     @pytest.mark.parametrize("from_pixels", [False, True])
     @pytest.mark.parametrize("from_depths", [False, True])
     @pytest.mark.parametrize("envname", RoboHiveEnv.available_envs)

test/test_transforms.py

@@ -146,7 +146,7 @@ class TransformBase:
 
     We ask for every new transform tests to be coded following this minimum requirement class.
 
-    Of course, specific behaviours can also be tested separately.
+    Of course, specific behaviors can also be tested separately.
 
     If your transform identifies an issue with the EnvBase or _BatchedEnv abstraction(s),
     this needs to be corrected independently.

torchrl/collectors/collectors.py

@@ -1412,7 +1412,7 @@ class _MultiDataCollector(DataCollectorBase):
             workers may charge the cpu load too much and harm performance.
         cat_results (str, int or None): (:class:`~torchrl.collectors.MultiSyncDataCollector` exclusively).
             If ``"stack"``, the data collected from the workers will be stacked along the
-            first dimension. This is the preferred behaviour as it is the most compatible
+            first dimension. This is the preferred behavior as it is the most compatible
             with the rest of the library.
             If ``0``, results will be concatenated along the first dimension
             of the outputs, which can be the batched dimension if the environments are
@@ -2160,7 +2160,7 @@ def iterator(self) -> Iterator[TensorDictBase]:
                 f"For MultiSyncDataCollector, `cat_results` indicates how the data should "
                 f"be packed: the preferred option and current default is `cat_results='stack'` "
                 f"which provides the best interoperability across torchrl components. "
-                f"Other accepted values are `cat_results=0` (previous behaviour) and "
+                f"Other accepted values are `cat_results=0` (previous behavior) and "
                 f"`cat_results=-1` (cat along time dimension). Among these two, the latter "
                 f"should be preferred for consistency across environment configurations. "
                 f"Currently, the default value is `'stack'`."
@@ -2948,7 +2948,7 @@ def _main_async_collector(
                     # If policy is on cuda and env on cpu (or opposite) we put tensors that
                     # are on cpu in shared mem.
                     if collected_tensordict.device is not None:
-                        # placehoder in case we need different behaviours
+                        # placehoder in case we need different behaviors
                         if collected_tensordict.device.type in ("cpu", "mps"):
                             collected_tensordict.share_memory_()
                         elif collected_tensordict.device.type == "cuda":

torchrl/collectors/distributed/ray.py

@@ -99,7 +99,7 @@ class RayCollector(DataCollectorBase):
 
     The class dictionary input parameter "ray_init_config" can be used to provide the kwargs to
     call Ray initialization method ray.init(). If "ray_init_config" is not provided, the default
-    behaviour is to autodetect an existing Ray cluster or start a new Ray instance locally if no
+    behavior is to autodetect an existing Ray cluster or start a new Ray instance locally if no
     existing cluster is found. Refer to Ray documentation for advanced initialization kwargs.
 
     Similarly, dictionary input parameter "remote_configs" can be used to specify the kwargs for

torchrl/data/datasets/openx.py

@@ -77,7 +77,7 @@ class for more information on how to interact with non-tensor data
               shuffle=False will also impact the sampling. We advice users to
               create a copy of the dataset where the ``shuffle`` attribute of the
               sampler is set to ``False`` if they wish to enjoy the two different
-              behaviours (shuffled and not) within the same code base.
+              behaviors (shuffled and not) within the same code base.
 
         num_slices (int, optional): the number of slices in a batch. This
             corresponds to the number of trajectories present in a batch.
@@ -134,7 +134,7 @@ class for more information on how to interact with non-tensor data
                 the dataset. This isn't possible at a reasonable cost with
                 `streaming=True`: in this case, trajectories will be sampled
                 one at a time and delivered as such (with cropping to comply with
-                the batch-size etc). The behaviour of the two modalities is
+                the batch-size etc). The behavior of the two modalities is
                 much more similar when `num_slices` and `slice_len` are specified,
                 as in these cases, views of sub-episodes will be returned in both
                 cases.

torchrl/data/replay_buffers/replay_buffers.py

@@ -1286,7 +1286,7 @@ def sample(
         if include_info is not None:
             warnings.warn(
                 "include_info is going to be deprecated soon."
-                "The default behaviour has changed to `include_info=True` "
+                "The default behavior has changed to `include_info=True` "
                 "to avoid bugs linked to wrongly preassigned values in the "
                 "output tensordict."
             )
@@ -1548,7 +1548,7 @@ class InPlaceSampler:
 
     .. warning:: This class is deprecated and will be removed in v0.7.
 
-    To be used cautiously as this may lead to unexpected behaviour (i.e. tensordicts
+    To be used cautiously as this may lead to unexpected behavior (i.e. tensordicts
     overwritten during execution).
 
     """

torchrl/data/replay_buffers/samplers.py

@@ -67,7 +67,7 @@ def update_priority(
         storage: Storage | None = None,
     ) -> dict | None:
         warnings.warn(
-            f"Calling update_priority() on a sampler {type(self).__name__} that is not prioritized. Make sure this is the indented behaviour."
+            f"Calling update_priority() on a sampler {type(self).__name__} that is not prioritized. Make sure this is the indented behavior."
         )
         return
 

torchrl/data/replay_buffers/storages.py

@@ -739,7 +739,7 @@ def set(  # noqa: F811
                     "A cursor of length superior to the storage capacity was provided. "
                     "To accommodate for this, the cursor will be truncated to its last "
                     "element such that its length matched the length of the storage. "
-                    "This may **not** be the optimal behaviour for your application! "
+                    "This may **not** be the optimal behavior for your application! "
                     "Make sure that the storage capacity is big enough to support the "
                     "batch size provided."
                 )

torchrl/data/replay_buffers/utils.py

@@ -802,7 +802,7 @@ def _path2str(path, default_name=None):
         if result == default_name:
             raise RuntimeError(
                 "A tensor had the same identifier as the default name used when the buffer contains "
-                f"a single tensor (name={default_name}). This behaviour is not allowed. Please rename your "
+                f"a single tensor (name={default_name}). This behavior is not allowed. Please rename your "
                 f"tensor in the map/dict or set a new default name with the environment variable SINGLE_TENSOR_BUFFER_NAME."
             )
         return result

torchrl/data/tensor_specs.py

@@ -524,7 +524,7 @@ class TensorSpec:
     """Parent class of the tensor meta-data containers.
 
     TorchRL's TensorSpec are used to present what input/output is to be expected for a specific class,
-    or sometimes to simulate simple behaviours by generating random data within a defined space.
+    or sometimes to simulate simple behaviors by generating random data within a defined space.
 
     TensorSpecs are primarily used in environments to specify their input/output structure without needing to
     execute the environment (or starting it). They can also be used to instantiate shared buffers to pass
@@ -5316,7 +5316,7 @@ def _unsqueezed_shape(shape: torch.Size, dim: int) -> torch.Size:
 
 
 class _CompositeSpecItemsView:
-    """Wrapper class that enables richer behaviour of `items` for Composite."""
+    """Wrapper class that enables richer behavior of `items` for Composite."""
 
     def __init__(
         self,

torchrl/envs/gym_like.py

@@ -149,7 +149,7 @@ def info_spec(self) -> Dict[str, TensorSpec]:
 class GymLikeEnv(_EnvWrapper):
     """A gym-like env is an environment.
 
-    Its behaviour is similar to gym environments in what common methods (specifically reset and step) are expected to do.
+    Its behavior is similar to gym environments in what common methods (specifically reset and step) are expected to do.
 
     A :obj:`GymLikeEnv` has a :obj:`.step()` method with the following signature:
 
@@ -508,7 +508,7 @@ def auto_register_info_dict(
         the info is filled at reset time.
 
         .. note:: This method requires running a few iterations in the environment to
-          manually check that the behaviour matches expectations.
+          manually check that the behavior matches expectations.
 
         Args:
             ignore_private (bool, optional): If ``True``, private infos (starting with

torchrl/envs/libs/pettingzoo.py

@@ -136,7 +136,7 @@ class PettingZooWrapper(_EnvWrapper):
     For example, you can provide ``MarlGroupMapType.ONE_GROUP_PER_AGENT``, telling that each agent should
     have its own tensordict (similar to the pettingzoo parallel API).
 
-    Grouping is useful for leveraging vectorisation among agents whose data goes through the same
+    Grouping is useful for leveraging vectorization among agents whose data goes through the same
     neural network.
 
     Args:
@@ -897,7 +897,7 @@ class PettingZooEnv(PettingZooWrapper):
     For example, you can provide ``MarlGroupMapType.ONE_GROUP_PER_AGENT``, telling that each agent should
     have its own tensordict (similar to the pettingzoo parallel API).
 
-    Grouping is useful for leveraging vectorisation among agents whose data goes through the same
+    Grouping is useful for leveraging vectorization among agents whose data goes through the same
     neural network.
 
     Args: