-
Notifications
You must be signed in to change notification settings - Fork 190
Publicity and privacy derived from modules seems wrong #323
Comments
Out of curiousity, if you run |
Yes, it does. Supposing I have the same directory tree as in my first content with an empty Given the directory tree from my initial comment and assuming that the contents of # public.py
def public():
pass # _private.py
def not_public():
pass then running
|
The public / private determination for modules shouldn't care about packages. What I suspect is happening here is that this Module method: def is_public(self):
return not self.name.startswith('_') or self.name.startswith('__') gets a fully qualified @willfrey, would you like to try this fix yourself and send a PR? |
Sure! |
This is the case. I don't believe there is a pull request for this yet. Is that correct? On a related note, is there a way to ignore |
Not yet. I'll be getting to this soon!
…On Wed, Jul 25, 2018 at 7:33 PM sqwishy ***@***.***> wrote:
gets a fully qualified self.name and thus is affected by the root package
where pydocstyle is run
This is the case. I don't believe there is a pull request for this yet. Is
that correct?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#323 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ANJVKWUy2JomqjmJjSY_fMazD2F8QGeqks5uKQBVgaJpZM4Uz9ow>
.
--
-Will Frey
|
For anyone else blocked by this, you might want (Note that that regex also excludes |
Based on the current implementation, the module
_private.py
here is considered publicsince
publicpackage
is considered public. With the current definition of a private module, it is impossible to have them under any public top-level package namespace. Should this be the case, though?Furthermore, let's consider a single private module
_module.py
with the contentsThe function
not_public
should not require a docstring because its only parent is private; however,pydocstyle _module.py
would still yield aD103
error.I will note that I can get around this by defining
__all__
to be empty, which is more explicit and probably a good practice even inside of a private module. That is, I can change_module.py
to containand I won't get the
D103
error anymore. That being said, this still isn't the behavior outlined in the documentation.It'd be nice to not get yelled at by
pydocstyle
while I'm working on an idea inside of a private submodule of my public package!Thank you!
The text was updated successfully, but these errors were encountered: