Internal interfaces could be explicitly marked
Try with explicitly marking the internal interfaces within the tensorflow package by adding a single leading underscore to their names, as recommended by the PEP 8 style guide. This will indicate that these interfaces are intended to be private and not to be accessed by users, preventing any unintended consequences. Renaming the `python` module to `_python` and following the same pattern for other internal interfaces will provide clarity and align with Python coding standards. @MO-Helena-Reid,
Could you please elaborate about your Feature. Also, please specify the Use Cases for this feature. Thank you! @tilakrayal
Use Cases: users attempting to access internal interfaces will have a clear, immediate indication that this is what they are doing. Users will no longer need to discover this information separately through other channels, as this information being contained in the import statement will make it impossible to import anything internal without seeing that it is marked private.

Under the current naming scheme, it is possible for users to import internal interfaces without realising they are doing so, because they are currently marked public, and to only discover their mistake later, such as when encountering unexpected behaviour.

The feature is just to mark all internal interfaces (for example, `tensorflow.python`) as private. The manner of doing so is as recommended by PEP 8. Is there something else specific you would like me to elaborate on? 
### Issue type

Feature Request

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

binary

### TensorFlow version

2.12.0

### Custom code

No

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

There are internal interfaces within the tensorflow package that I think would benefit from being marked more explicitly. According to [the PEP 8 style guide](https://peps.python.org/pep-0008/#public-and-internal-interfaces), *"Even with `__all__` set appropriately, internal interfaces (packages, modules, classes, functions, attributes or other names) should still be prefixed with a single leading underscore."*

While following all of PEP 8 to the letter is perhaps understandably not always adhered to in all projects, this particular section seems very reasonable. You can have no documentation for a module, and exclude it from `__all__`, both of which already indicate the module is not intended to be public, but it is still recommended to explicitly mark that module as private. Because this is commonly adhered to in the python ecosystem, some users may even expect modules not marked private to be intentionally public.

There exist old issues such as [this one](https://github.com/tensorflow/tensorflow/issues/33075) wherein it is stated that the only supported way to import anything is `import tensorflow` or possibly `from tensorflow.keras import ...`; and that `tensorflow.python` for example (or *"any other modules"*) is unsupported. To quote directly from that thread:

> so to confirm, `tf.python.keras` is *private*, intended for *development*, rather than public use? Thanks

> Yes, that's exactly the case. Anything under `tf.python` is private

If this module is intended to be private, then to be in accordance with the above guidelines, the module should be renamed from `python` to `_python`, as should all other internal interfaces. There seem several advantages to doing so: a user knows instantly that importing from `package._module` is dangerous (even if python technically permits it); an IDE may also be configured to treat such modules differently, such as excluding their contents from being displayed to the user in autocompletion, search results, etc. Doing so would also help prevent users such as the one in the issue above wondering why they encountered problems while using what on the surface looks like a public interface.

### Standalone code to reproduce the issue

```shell
Note that `import tensorflow.python` is possible, where we might expect `import tensorflow._python` indicating this is an internal interface not intended for the user to access. Running code with this import as a user would thus have unintended consequences.
```


### Relevant log output

_No response_