Exempt underscored namespaces et al from deprecation schedule

[dholth]

Checklist for submitter

• I am submitting a new CEP: Changes to Conda Deprecation Schedule.
  • I am using the CEP template by creating a copy cep-0000.md named cep-XXXX.md in the root level.
• I am submitting modifications to CEP XX.
• Something else: (add your description here).

Checklist for CEP approvals

• The vote period has ended and the vote has passed the necessary quorum and approval thresholds.
• A new CEP number has been minted. Usually, this is ${greatest-number-in-main} + 1.
• The cep-XXXX.md file has been renamed accordingly.
• The # CEP XXXX - header has been edited accordingly.
• The CEP status in the table has been changed to approved.
• The last modification date in the table has been updated accordingly.
• The table in the README has been updated with the new CEP entry.
• The pre-commit checks are passing.

[soapy1]

I like this idea!

[soapy1]

Is there a convention for when (and at what level) we might want to introduce __all__ into a module or not?

[dholth]

I would audit existing code especially projects under https://github.com/conda, add those, and also provide deliberate API exports for new code but not necessarily worry about __all__ when conda imports from itself.

[travishathaway]

I think this is a good idea and will help us more clearly delineate parts of code that are meant to be public and parts that are meant to be private.

I only wish that the conventions around API design in the Python community were a bit a stronger so documents like this wouldn't be necessary. Regardless, I think this will be not only useful for conda itself but all projects in the conda organization in GitHub.

[jaimergp]

I like this, and the reference to the Python type checking docs. Very useful. Can we add a practical example on how we would (and would not) apply this in the codebase? Thanks!