Updated torch.onnx Namespacing (markdown)

torch.onnx-Namespacing.md

@@ -2,7 +2,7 @@ This document lists conventions on namespacing in the `torch.onnx` module.
 
 ## Create private namespaces by default
 
-Make sure new functions and classes are private to the module by default. New modules should be private to torch.onnx by default.
+Make sure new functions and classes are **private to the module by default.** New modules should be **private to `torch.onnx` by default.**
 
 > Only "promote" them to public names when needed, by removing the prefix `_`
 
@@ -15,7 +15,7 @@ Make sure new functions and classes are private to the module by default. New mo
 ## Naming and usage convention
 
 1. Import only modules (in most cases).
-    - Import only the module instead of classes and functions to keep the namespace clean and provide readers with more context on where its members come from. For example, readers don’t need to backtrack to see `sleep` is a function from `time`, as opposed to a function defined in the file. https://google.github.io/styleguide/pyguide.html#22-imports
+    - **Import only the _module_ instead of classes and functions** to keep the namespace clean and provide readers with more context on where its members come from. For example, readers don’t need to backtrack to see `sleep` is a function from `time`, as opposed to a function defined in the file. https://google.github.io/styleguide/pyguide.html#22-imports
     - As another example,
 
         ![image](https://user-images.githubusercontent.com/11205048/169882197-f0a2ff8f-ec58-4610-a3c7-137ac68b3e53.png)
@@ -24,9 +24,9 @@ Make sure new functions and classes are private to the module by default. New mo
 2. `_module` is private to `torch.onnx`
     - Not for external consumption
     - If a module is inside a folder which has a `_` name. It is ok for the module to not be prefixed by `_` for simplicity.
-      - E.g. `torch.onnx._symbolic_opsets.symbolic_opset9` is good.
+        - E.g. `torch.onnx._symbolic_opsets.symbolic_opset9` is good.
 3. `_function` is private to its module, this means
-    - We should not use it in other modules (in most cases)
+    - We **should not use it in other modules** (in most cases)
     - Example:
 
         ```python
@@ -41,12 +41,12 @@ Make sure new functions and classes are private to the module by default. New mo
 
         for it to be consumed internally.
 
-        Explanation: `_symbolic_helper` (as an example name; doesn’t mean we should hide what is already exposed) is a private module to `torch.onnx` so we can import it in other modules. `unimplemented` is not private to its own module, so we can use it in another module.
+        **Explanation:** `_symbolic_helper` (as an example name; doesn’t mean we should hide what is already exposed) is a private module to `torch.onnx` so we can import it in other modules. `unimplemented` is not private to its own module, so we can use it in another module.
     - This provides clarity to readers and consistency in code structure, reinforcing the convention that private functions should not be used outside of their modules.
     - Additionally, a function not prefixed by `_` signals that we should create a unit test for it. A function prefixed with `_` may be implementation details not worthy of unit tests.
     - It keeps type checkers happy by only using non-private functions in a module.
-4. When a name is aliased in `torch.onnx.__init__`, import them from where they are defined. Do not import the alias.
-    - Why? It can reduce the possibility of loading a partially initialized `torch.onnx` (which causes errors). It also makes it clear to readers where the names come from.
+4. When a name is aliased in `torch.onnx.__init__`, import them from where they are defined. **Do not import the alias for internal use.**
+    - **Why?** It can reduce the possibility of loading a _partially initialized_ `torch.onnx` (which causes errors). It also makes it clear to readers where the names come from.
     - Example:
 
         In `__init__.py` we alias