Skip to content

Conversation

@erlend-aasland
Copy link

No description provided.

Comment on lines 2655 to +2658

@functools.cached_property
def new_or_init(self) -> bool:
return self.name in ("__new__", "__init__")
Copy link

@AlexWaygood AlexWaygood Aug 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to be a cached_property anymore; we can just assign it eagerly in __post_init__:

Suggested change
@functools.cached_property
def new_or_init(self) -> bool:
return self.name in ("__new__", "__init__")
self.new_or_init = self.name in ("__new__", "__init__")

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, that's fine. But what do you think of this refactor?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I did not mean to be dismissive! Thanks for the suggestion :)

Copy link

@AlexWaygood AlexWaygood Aug 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, you're right; the overall concept is more important!

I think it looks good. Conceptually, I think these aren't really distinct categories of methods; they're subcategories of (respectively) CALLABLE and CLASS_METHOD. So we're simplifying some code while also making it conceptually cleaner, which is nice.

The benefit doesn't seem huge to me right now, but I'll trust you when you say that this clears the way for further refactorings :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to formulate my motivation for doing this. I just need to find time to jot it down :)

) -> str | None:
type, _ = correct_name_for_self(f)
if f.kind in (METHOD_INIT, METHOD_NEW, STATIC_METHOD, CLASS_METHOD):
if f.kind in (STATIC_METHOD, CLASS_METHOD) or f.name == "__init__":
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if f.kind in (STATIC_METHOD, CLASS_METHOD) or f.name == "__init__":
if f.kind in (STATIC_METHOD, CLASS_METHOD) or f.new_or_init:

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reads slightly nicer.

f: Function
) -> tuple[str, str]:
if f.kind in (CALLABLE, METHOD_INIT):
if f.kind is CALLABLE or f.name == "__init__":
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if f.kind is CALLABLE or f.name == "__init__":
if f.kind is CALLABLE:

@AlexWaygood
Copy link

AlexWaygood commented Aug 17, 2023

I think you should assign three attributes in __post_init__:

class Function:
    # <-- snip -->
    def __post_init__(self) -> None:
        # <-- snip -->
        self.init_method = self.name == "__init__"
        self.new_method = self.name == "__new__"
        self.new_or_init = self.init_method or self.new_method

Then you wouldn't have to have so many "magic strings" everywhere -- everywhere you're currently doing if f.name == "__init__", you can just do if f.init_method

@erlend-aasland
Copy link
Author

I think you should assign three attributes in __post_init__:

class Function:
    # <-- snip -->
    def __post_init__(self) -> None:
        # <-- snip -->
        self.init_method = self.name == "__init__"
        self.new_method = self.name == "__new__"
        self.new_or_init = self.init_method or self.new_method

Then you wouldn't have to have so many "magic strings" everywhere -- everywhere you're currently doing if f.name == "__init__", you can just do if f.init_method

Yeah, that's neat. I thought of doing something like that; I'm not a fan of the name == "__init__" comparisons either.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants