-
Notifications
You must be signed in to change notification settings - Fork 189
It should be possible to ignore "magic methods" like __str__ #60
Comments
PEP 257 does not say explicitly what to do with magic methods. But is sais the follwoing:
Which makes me think that methods like 2 open questions:
|
I think so. All things considered, the magic methods work because they're technically public. No one will ever call: |
I think the correct interpretation of PEP257 is irrelevant. We should allow If a user would add pep257.py to a build script or commit hook and expect
|
No, the correct interpretation of PEP 257 should be the default behavior.
Agree. This should be done through command-line flags, etc. |
I agree.
|
Same for
I think that developers should spend time write meaningful docstring rather than add dumb docstring to please a tool. |
I agree that magic methods don’t need docstrings (the language defines their interface and role), with a possible exception of init. I tend to document constructors in the class docstring, but sometimes it makes more sense to add a docstring to init. |
I agree with @merwok and @adiroiban. The behavior of most magic methods should be completely obvious based on the rest of the class, but |
And so...? Is now possible disable this with a command-flag or nah? |
Not as of now.
|
I was thinking about how to implement this. If possible, I would like all customization for errors to happen by ignoring and selecting errors, so naturally I would like to have a new error code for magic methods Some questions:
|
I would say any magic method that takes a variable number of arguments should be documented. The arguments to (and behavior of) methods like |
From what I see, the only magic methods with a variable number of arguments are |
See a summary of magic methods here: http://www.rafekettler.com/magicmethods.html#appendix1 |
👍 |
I'm running the latest release (1.0), which it looks like this landed in, but I'm finding I have to explicitly pass |
@jab The new error is not suppressed by default. It exists so that you could suppress it, if you want to. |
@Nurdok Did you mean not suppressed by default? |
@jab yes, edited. |
Thanks for clarifying. |
There's no reason to force documentation for methods such as
__str__
,__unicode__
,__repr__
, etc.The text was updated successfully, but these errors were encountered: