Skip to content

[python-package] prefix all internal object names with "_" #5313

Closed
@jameslamb

Description

Short Description

I'm opening this RFC to propose the following:

all objects in the Python package which are intended to be internal should have names beginning with _

The convention "anything starting with _ is internal" is common in Python programming. If LightGBM's Python package followed that convention consistently, it would simplify LightGBM's position on which parts of the Python package are considered "internal" and subject to breaking changes in any release.

Detailed Description

In pursuit of the v4.0.0 release (#5153), we have been accepting breaking changes which simplify the project and reduce its maintenance burden, so that limited maintainer time can be focused on providing a good experience with LightGBM's main functionality.

I think "all internal objects should begin with _" is one such type of change. Making it clearer which parts of the Python package are considered internal reduces the surface area of the public API which users need to consider, and increases contributors' flexibility to change implementations without breaking user code.

R packages support a "namespace" concept (see "Writing R extensions"), which clearly separates exported and internal objects, and I think that mechanism has been really helpful. The closest thing that Python has, to my knowledge, is the __all__ member for modules (https://docs.python.org/3/tutorial/modules.html#importing-from-a-package). __all__ controls the behavior of "star imports".

For example, if you run the following:

from lightgbm import *
dir()

the only LightGBM objects you'll see are those in the package's __all__.

This mechanism is a good start, but prefixing all internal objects with _ would be an even stronger signal about which things are internal. It would also improve the consistency of the Python package's code.

Specific Proposal

expand to see original proposal (click me)

I am proposing that the following be prefixed with a _ and treated as internal:

Considerations for Implementation

Check that any name being modified is only used at runtime and not part of the state for objects like Booster or LGBMClassifier which might be pickled (since pickle only stores references to imports and expects to be able to reference them when running load()).

Status: Accepted

@StrikerRUS @jmoralez @shiyu1994 @guolinke Whenever you have time, will you please comment here on whether or not you support this proposal? Thank you for your time and consideration.

This was originally opened as a request for comment, but it's been accepted and we're now accepting contributions to make more of the Python package's namespace private?

How to Contribute

Anyone is welcome to submit a pull request to help contribute to this effort.

Please limit pull requests to 1 function/method/module per pull request, to make them easier to review.

When you open pull requests, please put Contributes to #5313 in the description.

Add __all__ entries to modules.

Prefix objects, functions, class attributes with _

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions