Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Support auto-filtering of members based on __all__ #78

Copy link
Copy link
Closed
@pawamoy

Description

@pawamoy
Issue body actions

Is your feature request related to a problem? Please describe.
By convention, Python devs use __all__ both to control what gets imported by wildcard imports, and in the same sense, define which objects are public. Currently, all non-private members will be rendered by mkdocstrings, instead of members defined in __all__.

Describe the solution you'd like
An option (enabled by default?) to tell mkdocstrings to only render objects that are added to __all__.

Describe alternatives you've considered
/

Additional context
Discussed on Gitter:

Kludex (Marcelo Trylesinski)
can I only load docstrings from objects in __all__?

pawamoy
Not natively I'm afraid. __all__ is meant for wildcard imports (explicit re-exports), so we use it like such, and to know if an alias should be resolved. There's no way yet to mark objects as "public" except for the underscore prefix convention (marking objects as private, therefore marking the rest as public)

Kludex (Marcelo Trylesinski)
thanks

dhirschfeld (Dave Hirschfeld)
__all__ is used for wildcard imports, but it's also a fairly strong convention that it denotes the public api of a module
What else is an import * for, other than import all public functions
Naming a function with an _ prefix implicitly defines it as private, by convention. Also, by convention, the public api of a module can be explicitly defined by listing it in __all__
I'm ok if tools want to ignore this long-standing convention however I think they should at least make respecting __all__ as the explicitly defined public api of a module an option
I'm not sure where the distinction between "explicitly re-exported" and public comes from - to me it is absolutely synonymous with "public"
...which means that if it's not "explicitly exported" it's intended to be private to that module... however it is named.

pawamoy
well, something could be public but not re-exported (for example to avoid ambiguity or conflicts when other modules provide an object with the same name)
I'm not against adding an option to use __all__ as the list of public objects, it's just that I'm not really satisfied with the whole situation :)
I guess the fact that from thing import * without __all__ defined imports all objects except those starting with an underscore is a strong argument in favor of "__all__ defines what is public"

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureNew feature or requestNew feature or requestinsidersCandidate for InsidersCandidate for Insiders

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.