annotations.py 4.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141
  1. from ray.rllib.utils.deprecation import Deprecated
  2. def override(cls):
  3. """Decorator for documenting method overrides.
  4. Args:
  5. cls (type): The superclass that provides the overridden method. If this
  6. cls does not actually have the method, an error is raised.
  7. Examples:
  8. >>> class TorchPolicy(Policy):
  9. ... ...
  10. ... # Indicates that `TorchPolicy.loss()` overrides the parent
  11. ... # Policy class' own `loss method. Leads to an error if Policy
  12. ... # does not have a `loss` method.
  13. ... @override(Policy)
  14. ... def loss(self, model, action_dist, train_batch):
  15. ... # ...
  16. """
  17. def check_override(method):
  18. if method.__name__ not in dir(cls):
  19. raise NameError("{} does not override any method of {}".format(
  20. method, cls))
  21. return method
  22. return check_override
  23. def PublicAPI(obj):
  24. """Decorator for documenting public APIs.
  25. Public APIs are classes and methods exposed to end users of RLlib. You
  26. can expect these APIs to remain stable across RLlib releases.
  27. Subclasses that inherit from a ``@PublicAPI`` base class can be
  28. assumed part of the RLlib public API as well (e.g., all trainer classes
  29. are in public API because Trainer is ``@PublicAPI``).
  30. In addition, you can assume all trainer configurations are part of their
  31. public API as well.
  32. Examples:
  33. >>> # Indicates that the `Trainer` class is exposed to end users
  34. ... # of RLlib and will remain stable across RLlib releases.
  35. ... @PublicAPI
  36. ... class Trainer(tune.Trainable):
  37. ... ...
  38. """
  39. return obj
  40. def DeveloperAPI(obj):
  41. """Decorator for documenting developer APIs.
  42. Developer APIs are classes and methods explicitly exposed to developers
  43. for the purposes of building custom algorithms or advanced training
  44. strategies on top of RLlib internals. You can generally expect these APIs
  45. to be stable sans minor changes (but less stable than public APIs).
  46. Subclasses that inherit from a ``@DeveloperAPI`` base class can be
  47. assumed part of the RLlib developer API as well.
  48. Examples:
  49. >>> # Indicates that the `TorchPolicy` class is exposed to end users
  50. ... # of RLlib and will remain (relatively) stable across RLlib
  51. ... # releases.
  52. ... @DeveloperAPI
  53. ... class TorchPolicy(Policy):
  54. ... ...
  55. """
  56. return obj
  57. def ExperimentalAPI(obj):
  58. """Decorator for documenting experimental APIs.
  59. Experimental APIs are classes and methods that are in development and may
  60. change at any time in their development process. You should not expect
  61. these APIs to be stable until their tag is changed to `DeveloperAPI` or
  62. `PublicAPI`.
  63. Subclasses that inherit from a ``@ExperimentalAPI`` base class can be
  64. assumed experimental as well.
  65. Examples:
  66. >>> class TorchPolicy(Policy):
  67. ... ...
  68. ... # Indicates that the `TorchPolicy.loss` method is a new and
  69. ... # experimental API and may change frequently in future
  70. ... # releases.
  71. ... @ExperimentalAPI
  72. ... def loss(self, model, action_dist, train_batch):
  73. ... # ...
  74. """
  75. return obj
  76. def OverrideToImplementCustomLogic(obj):
  77. """Users should override this in their sub-classes to implement custom logic.
  78. Used in Trainer and Policy to tag methods that need overriding, e.g.
  79. `Policy.loss()`.
  80. Examples:
  81. >>> @overrides(TorchPolicy)
  82. ... @OverrideToImplementCustomLogic
  83. ... def loss(self, ...):
  84. ... # implement custom loss function here ...
  85. ... # ... w/o calling the corresponding `super().loss()` method.
  86. """
  87. return obj
  88. def OverrideToImplementCustomLogic_CallToSuperRecommended(obj):
  89. """Users should override this in their sub-classes to implement custom logic.
  90. Thereby, it is recommended (but not required) to call the super-class'
  91. corresponding method.
  92. Used in Trainer and Policy to tag methods that need overriding, but the
  93. super class' method should still be called, e.g.
  94. `Trainer.setup()`.
  95. Examples:
  96. >>> @overrides(Trainable)
  97. ... @OverrideToImplementCustomLogic_CallToSuperRecommended
  98. ... def setup(self, config):
  99. ... # implement custom setup logic here ...
  100. ... super().setup(config)
  101. ... # ... or here (after having called super()'s setup method.
  102. """
  103. return obj
  104. # Backward compatibility.
  105. Deprecated = Deprecated