Skip to content

Split public and dunder methods #1

Description

@HEROgold

Amazing project!!

I would however, like to have more control about dunder (init, get etc) vs public.
In fact, i'd like a group for generic dunder methods (get, set etc), and a group for obj creational dunders (init, new init_subclass). These are usually only used in niche/specialized cases.

Currently, dunder init, sits after a classmethod with the following configuration:

[tool.undersort]
order = ["public", "protected", "private"]
method_type_order = ["static", "class", "instance"]
    @classmethod
    def default(cls, section: str, setting: str, value: VT) -> Callable[[Callable[P, F]], Callable[P, F]]:
    def __init__(self ) -> None:

I personally like to have dunder methods before anything else.

    def __init__(self ) -> None:
    @classmethod
    def default(cls, section: str, setting: str, value: VT) -> Callable[[Callable[P, F]], Callable[P, F]]:

Example two: dunder init and dunder string are not grouped together at all. These are left as-is because they're all considered public. Regardless of configuration, the tool doesn't change the order of the next 3 methods.

    def __init__(self) -> None:
    def random_public():
    def __str__(self) -> str:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions